[jira] [Commented] (CAMEL-4279) Add support for the new TLS for spring-ws if possible

["Babak Vahdat (Commented) (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CAMEL-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256621#comment-13256621 ] 

Babak Vahdat commented on CAMEL-4279:
-------------------------------------

Following a feedback of mine regarding the provided patch for CAMEL-4998 which went live together with the patch provided by this ticket:

- There's *now* a regression failure by ProducerRemoteRouteTimeOutTest.callStockQuoteWebserviceJDKWith5000MillSecondsTimeout() which
doesn't pass anymore. On CI-Server of course we don't see this as we've got @Ignore annotation on those tests. Reason of the failure is that now we do no more rely on instanceof but reference-equality by HttpUrlConnectionMessageSender.class, so following is what's going on: If you run the tests inside your IDE or directly through maven then as the test callStockQuoteWebserviceJDKWith3MillSecondsTimeout gets invoked beforehand it sets an instance of AbstractHttpWebServiceMessageSenderDecorator as WebServiceMessageSender with the timeout of 3 milliseconds. Later on it's callStockQuoteWebserviceJDKWith5000MillSecondsTimeout turn to be run and as *none* of the conditions below holds the AbstractHttpWebServiceMessageSenderDecorator from previous test still remains inside WebServiceTemplate as the single WebServiceMessageSender:

{code}
if (messageSender instanceof CommonsHttpMessageSender)
{code}

{code}
 else if (messageSender.getClass().equals(HttpUrlConnectionMessageSender.class))
{code}

So actually we asked for a timeout of 5 seconds but in fact there was a 3 milliseconds timeout getting into the account. Which causes the test failure. Another proof of this explanation is (in case you don't want to debug into the code) if you only run the test callStockQuoteWebserviceJDKWith5000MillSecondsTimeout *alone* then it will pass!

- Resetting the timeout back to 0 is currently missing if we *once* set the timeout to a value > 0 then the timeout is spiked to that value *forever*. Consider the following trivial case where we use *the same* WebServiceTemplate for 2 different webservice calls inside a route:

{code}
from(...)
  ...
   ...
    to("spring-ws:http://xyz?timeout=3000&webServiceTemplate=#myWebServiceTemplate")
     ...
      ...
       to("spring-ws:http://abc?webServiceTemplate=#myWebServiceTemplate")
  ...
{code}

With the current logic in place the second call to "http://abc" get's also invoked with a read timeout of 3 seconds as well which is completely wrong! The reason for this is similar to the previous point I did already mention above, however the difference here is that now in contrast to the regression case above where the second call asked to 5000 milliseconds here we do *not* ask for a timeout at all, but still we get one, in this case 3 seconds!

Also currently we don't own a test case for this where we use the same WebServiceTemplate object once with and once without an explicit timeout. To remedy this behaviour the logic should set the timeout *explicitly* to 0 if no timeout option has been given. That's the logic should *clear out* any possibly set timeout value *done previously*.

Some tiny cosmetic points:

- SSLContextParametersLocalRouteTest-context.xml runs a sun-jdk specific HttpsServer:

{code}
sun.net.httpserver.HttpsServerImpl
{code}

This class could be missing on other JDKs (like IBM one) and it's behaviour *will be dependent* on the JDK *build number*. We should better never & ever use sun.* packages and for example use jetty (the same version as used in camel trunk itself):

http://www.oracle.com/technetwork/java/faq-sun-packages-142232.html
 
- In contrast to AbstractHttpWebServiceMessageSender which is *really abstract* the class AbstractHttpWebServiceMessageSenderDecorator is not abstract at all, so better remove the Abstract prefix by it's name to avoid any missunderstanding

- In the method SpringWebserviceProducer.prepareMessageSenders() we have got both the "instanceof" as well as "reference equality" usage (java.lang.Class doesn't override java.lang.Object.equals() method):

{code}
if (messageSender instanceof CommonsHttpMessageSender) {
{code}

{code}
} else if (messageSender.getClass().equals(HttpUrlConnectionMessageSender.class)) {
{code}

But my understanding was that the new logic will avoid any "instanceof" usage as we don't want to get sub-classes that might have been otherwise injected. But this could be the case for CommonsHttpMessageSender as well! Do I miss something here?

I hope you could follow my poor english!

                
> 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