[
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
