[
https://issues.apache.org/jira/browse/CAMEL-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13232895#comment-13232895
]
David Valeri commented on CAMEL-4998:
-------------------------------------
CAMEL-4279 calls for adding support for Camel's JSSE configuration utility to
the Camel Spring WS component. I see a clear route to get there; however, in
working through the code to implement this feature, I noticed that CAMEL-4998
introduced some sketchy, in my opinion, code in its implementation.
The code subclasses some Spring classes to mix in the needed functionality;
however, the way these subclasses are used can be problematic for two reasons:
The subclass
org.apache.camel.component.spring.ws.SpringWebserviceProducer.CamelHttpsUrlConnectionMessageSender
uses reflection to access private fields of its parent class. This won't fly
in the scenario where the code is running on a hardened VM where such trickery
is usually disallowed for user code (although it is possible to grant an
exception this Camel component).
The instanceof test used may identify an end-user's custom sub-class of the
built-in MessageSender implementations are replace it with one of the custom
Camel versions thus wiping out the end-user's intended configuration without
warning.
The desired outcome, allow users to set the timeout, can be achieved using the
decorator pattern. Unfortunately, it is not a 100% clean decorator
implementation because the methods we want to decorate are not defined in an
interface class but in another class. Regardless, it is still very possible to
avoid the reflection calls. One can create a decorator of
HttpUrlConnectionMessageSender instances by subclassing
HttpUrlConnectionMessageSender and then overriding all methods to pass through
to a delegate while also introducing the tweak to the timeout setting as called
for in CAMEL-4998. All methods in HttpUrlConnectionMessageSender are public
and intended for overriding and methods from HttpUrlConnectionMessageSender's
super-class are not final, intended for overriding, and defined in an interface.
While the decorator approach satisfies the desire to make the timeout
configurable, it might still clobber an end-user's customization from their
MessageSender sub-class. It would be great if it were possible to detect if
the MessageSenders being decorated/replaced were introduced by default or if
they were customized by the end user in some way; however, with the default
behavior of Spring WS being configurable through properties files, Camel
allowing the end-user to inject their own WebServiceTemplate instance, and the
use of instanceof, I don't think we can cover all cases. What I think we can
do is follow the principal of least surprise with the decorator pattern
(doesn't clobber the original MessageSender completely) and document that this
occurs when the timeout or SSLContextParameters configuration options are used.
I'd be happy to refactor this portion of the code as part of CAMEL-4279 and add
some logging to indicate what is going on if there are no other reasons that I
am missing.
> Provide the timeout option for the SpringWebserviceProducer
> -----------------------------------------------------------
>
> Key: CAMEL-4998
> URL: https://issues.apache.org/jira/browse/CAMEL-4998
> Project: Camel
> Issue Type: New Feature
> Components: camel-spring-ws
> Affects Versions: 2.9.0
> Reporter: Babak Vahdat
> Assignee: Babak Vahdat
> Fix For: 2.10.0
>
>
> See
> http://camel.465427.n5.nabble.com/How-to-implement-requestTimeout-in-the-spring-ws-component-td5469281.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
