camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Babak Vahdat (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CAMEL-4279) Add support for the new TLS for spring-ws if possible
Date Wed, 18 Apr 2012 14:58:29 GMT

    [ 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

        

Mime
View raw message