[
https://issues.apache.org/jira/browse/CAMEL-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257999#comment-13257999
]
David Valeri commented on CAMEL-4279:
-------------------------------------
Usage of instanceof for detecting Commons HTTP message senders. Yes it should
be an instanceof initially, but I should also be doing a direct comparison
later before setting the timeout in order to determine if it is one of the
built-in implementations or a user's subclass. Good catch.
After looking into the test in question, ProducerRemoteRouteTimeOutTest, here
is what I am seeing.
* WebServiceTemplate in SpringWebserviceConfiguration is affected by URI
parameters in the endpoint URI. In this test, a shared WebServiceTemplate is
set by 'webServiceTemplate=#commonsHttpWebServiceTemplate' in the endpoint URIs.
* The state of the WebServiceTemplate in use is also affected by the timeout
URI parameter (it replaces/decorates the message senders in the
WebServiceTemplate).
* If you inject the same WebServiceTemplate into a number of endpoints and one
of them uses the timeout URI parameter, the state of the WebServiceTemplate
will be altered. Since the state is shared between all endpoints that were
setup with the shared WebServiceTemplate, each new endpoint will affect the
state of the previous endpoint(s).
* In the old implementation, the timeout applied to the last endpoint used
would be applied to all previous endpoints sharing the WebServiceTemplate
(instanceof would have caught the custom Camel subclasses and replaced them).
In the new implementation, the first timeout will be applied to all subsequent
endpoints (direct class comparison only matches the first time, then later
endpoints don't trigger the matching and subsequent reconfiguration).
* What I am now seeing is that
org.apache.camel.component.spring.ws.SpringWebserviceProducer.prepareMessageSenders(SpringWebserviceConfiguration)
is actually invoked when a message is sent and not when an producer is
initialized as I had previously thought. This situation is bad. I think it
should be done when the producer is created, if at all. If it is done on every
producer invocation, eventually there will be concurrency issues under load as
multiple producers are mucking around with unsynchronized access to the
WebServiceTemplate. This risky implementation is what allowed the test to pass
originally. The timeout was set to whatever the current endpoint wants when
the endpoint is invoked. This is great until we run into concurrent usage of
two endpoints sharing the same WebServiceTemplate.
* Long story short, I'm not seeing how this is any more broken than the
original implementation. The test in question may now be failing, but I think
it was giving a false sense of proper function to begin with.
This situation is also true of the other fields on a shared WebServiceTemplate.
Anything we do that affects the state in there for one endpoint will affect
all other endpoints using the same WebServiceTemplate.
We can keep the existing functionality, but prepareMessageSenders has to be
moved to producer instantiation and we will need to put warnings in the
documentation about not using timeout or sslContextParameters when you use a
custom WebServiceTemplate.
I've already committed changes to move prepareMessageSenders, update the tests
so that they don't alter a shared WebServiceTemplate, and add an additional
test and log message for the message sender detection.
> Add support for the new TLS for spring-ws if possible
> -----------------------------------------------------
>
> Key: CAMEL-4279
> URL: https://issues.apache.org/jira/browse/CAMEL-4279
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring-ws
> Affects Versions: 2.8.0
> Reporter: Claus Ibsen
> Assignee: David Valeri
> Labels: security
> Fix For: 2.10.0
>
>
> David do you mind checking if its possible to add support for the new TLS you
> did, for spring-ws component as well?
> See nabble
> http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4643001.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
