[JBoss JIRA] (JBTM-986) Setup client side handler chain if Service wsdl contains WS-Policy Assertion
11:08 a.m.
Setup client side handler chain if Service wsdl contains WS-Policy Assertion
-----------------------------------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
See the "Policy Assertions" section of the WS-BA and WS-AT specification for
what this should implement. Ideally this feature would be turned on/off via an annotation,
however we should take a look to see if WS-Policy mandates a particular method.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:38 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Summary: Automatically setup the client side handler chain (was: Setup client
side handler chain if Service wsdl contains WS-Policy Assertion )
Description:
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the
client stub to manage transaction context propagation. The code required to do this is as
follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such that
the middleware knows to setup the handler chain. I'm not sure what support already
exists for injecting WS client stubs. This needs to be investigated first.
was:See the "Policy Assertions" section of the WS-BA and WS-AT specification
for what this should implement. Ideally this feature would be turned on/off via an
annotation, however we should take a look to see if WS-Policy mandates a particular
method.
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:38 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Description:
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the
client stub to manage transaction context propagation. The code required to do this is as
follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such that
the middleware knows to setup the handler chain. I'm not sure what support already
exists for injecting WS client stubs. This needs to be investigated first.
was:
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the
client stub to manage transaction context propagation. The code required to do this is as
follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such that
the middleware knows to setup the handler chain. I'm not sure what support already
exists for injecting WS client stubs. This needs to be investigated first.
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:22 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Priority: Minor (was: Major)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:59 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Priority: Major (was: Minor)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:32 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Priority: Minor (was: Major)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:05 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson commented on JBTM-986:
------------------------------------
Here's examples of how @WebServiceRe is used:
http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
http://anonsvn.jboss.org/repos/jbossws/shared-testsuite/trunk/testsuite/s...
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 5.0.0.M2
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such
that the middleware knows to setup the handler chain. I'm not sure what support
already exists for injecting WS client stubs. This needs to be investigated first.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:01 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Fix Version/s: 5.0.0.Final
(was: 5.0.0.M2)
Priority: Major (was: Minor)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.Final
Original Estimate: 1 week
Remaining Estimate: 1 week
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
3:01 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Original Estimate: 1 week
Remaining Estimate: 1 week
Description:
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the
client stub to manage transaction context propagation. The code required to do this is as
follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
was:
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to the
client stub to manage transaction context propagation. The code required to do this is as
follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
h2. Using WS-Policy
If the Service WSDL specifies a WS-Policy assertion, we know that WS-AT or WS-BA is
required/supported and we should be able to setup this handler chain automatically.
Another benefit is that we can catch, on the client side, the situation where no WS-AT or
WS-BA transaction context is present. Currently we leave it up to the service to detect
and as a result we have no control over how this fault will be propagated back to the
client. For example, a WrongStateException could be thrown when the service tries to
enlist a participant and a transaction is not present. The Client may receive a generic
fault message back or, in this case some or all of the WrongStateException. In either
case, the developer of the Client is unlikely to realise that this is due to there not
being a transaction present when the service was invoked. If the service mandates a WS-AT
or WS-BA transaction, but none is present, then the client handler throws a suitable
exception explaining what went wrong. If the service supports (i.e. it is optional) a
WS-AT or WS-BA transaction, then the interceptor ignores the situation where non exists.
CXF seems to have a plugin point for adding WS-Policy assertion handlers. This could be
the right integration point for this feature. This is to be investigated.
h2. Without WS-Policy
It could be possible to inject a WS client stub and annotate the injection point such that
the middleware knows to setup the handler chain. I'm not sure what support already
exists for injecting WS client stubs. This needs to be investigated first.
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Priority: Minor
Fix For: 5.0.0.Final
Original Estimate: 1 week
Remaining Estimate: 1 week
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Work on JBTM-986 started by Paul Robinson.
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.Final
Original Estimate: 1 week
Remaining Estimate: 1 week
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:54 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Fix Version/s: 5.0.1.Final
(was: 5.0.0.Final)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.1.Final
Original Estimate: 1 week
Remaining Estimate: 1 week
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:35 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Original Estimate: 3 days (was: 1 week)
Remaining Estimate: 3 days (was: 1 week)
Fix Version/s: 5.0.0.Final
(was: 5.0.1.Final)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.0.Final
Original Estimate: 3 days
Remaining Estimate: 3 days
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:43 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Fix Version/s: 5.0.1.Final
(was: 5.0.0.Final)
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Fix For: 5.0.1.Final
Original Estimate: 3 days
Remaining Estimate: 3 days
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:47 a.m.
New subject: [JBoss JIRA] (JBTM-986) Automatically setup the client side handler chain
[
https://issues.jboss.org/browse/JBTM-986?page=com.atlassian.jira.plugin.s...
]
Paul Robinson updated JBTM-986:
-------------------------------
Labels: assign (was: )
Automatically setup the client side handler chain
-------------------------------------------------
Key: JBTM-986
URL: https://issues.jboss.org/browse/JBTM-986
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: XTS
Reporter: Paul Robinson
Assignee: Paul Robinson
Labels: assign
Fix For: 5.0.0.Final
Original Estimate: 3 days
Remaining Estimate: 3 days
When invoking a WS-AT or WS-BA Web service, the client side handler has to be added to
the client stub to manage transaction context propagation. The code required to do this is
as follows:
{code}
BindingProvider bindingProvider = (BindingProvider) client;
List<Handler> handlers = new ArrayList<Handler>(1);
handlers.add(new JaxWSHeaderContextProcessor());
bindingProvider.getBinding().setHandlerChain(handlers);
{code}
This is not very user friendly.
This could be done using a JAX-WS feature passed to the Client-side port. The default
should be "enabled" providing the feature is enabled in the XTS server config.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
4376
days inactive
4749
days old
jbossts-issues@lists.jboss.org
13 comments
3 participants
participants (3)
-
Paul Robinson (Created) (JIRA) -
Paul Robinson (JIRA)
-
Paul Robinson (Updated) (JIRA)