You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Eoghan Glynn (JIRA)" <ji...@apache.org> on 2006/09/20 10:38:22 UTC
[jira] Created: (CXF-100) Config-driven mechanism for specifying
native Interceptor and JAX-WS Handler chains
Config-driven mechanism for specifying native Interceptor and JAX-WS Handler chains
-----------------------------------------------------------------------------------
Key: CXF-100
URL: http://issues.apache.org/jira/browse/CXF-100
Project: CeltiXfire
Issue Type: New Feature
Components: Configuration
Reporter: Eoghan Glynn
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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (CXF-100) Config-driven mechanism for specifying
native Interceptor and JAX-WS Handler chains
Posted by "Andrea Smyth (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/CXF-100?page=all ]
Andrea Smyth reassigned CXF-100:
--------------------------------
Assignee: Andrea Smyth
> Config-driven mechanism for specifying native Interceptor and JAX-WS Handler chains
> -----------------------------------------------------------------------------------
>
> Key: CXF-100
> URL: http://issues.apache.org/jira/browse/CXF-100
> Project: CeltiXfire
> Issue Type: New Feature
> Components: Configuration
> Reporter: Eoghan Glynn
> Assigned To: Andrea Smyth
>
> 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.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CXF-100) Config-driven mechanism for specifying
native Interceptor and JAX-WS Handler chains
Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
[ 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.