camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Valeri (Commented) (JIRA)" <>
Subject [jira] [Commented] (CAMEL-4279) Add support for the new TLS for spring-ws if possible
Date Fri, 20 Apr 2012 03:15:37 GMT


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

* 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
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:
>             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

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message