[
https://issues.apache.org/jira/browse/CAMEL-4279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13259580#comment-13259580
]
Babak Vahdat commented on CAMEL-4279:
-------------------------------------
- Regarding "Why are those tests @Ignore?"
The reason is already documented by the @Ignore annotation itself:
{code}
Run manually, makes connection to external webservice.
{code}
So just because http://www.webservicex.net is down you don't want Jenkins
(CI-Server) think something in camel source itself is wrong as the tests fail.
And believe me that site is very often down (I've checked it many times). AFAIK
there're 4 reasons why you would find @Ignore on camel-xyz tests:
- A JIRA ticket is in progress and the test tries to demonstrate the problem
being addressed by the ticket.
- No JIRA ticket is open but the test simply fails for whatever reason and
hopefully somebody can fix the code/test in the future:
{code}
org.apache.camel.component.hazelcast.testAddInstance()
{code}
- An external system is being called and we don't want the test result being
dependent on if the external system is up and running and also behaves as we
would expect from the camel component point of view. There're lots of examples
for this in camel source itself:
{code}
org.apache.camel.component.ahc.AhcGoogleTest
org.apache.camel.component.atom.AtomHttpConsumerTest
{code}
- The test is a performance-measurement / smoke-test:
{code}
org.apache.camel.builder.saxon.XPathSplitChoicePerformanceTest.testXPathPerformanceRoute()
{code}
That said, a more elegant solution would have been to provide a webservice
inside the running JVM (using spring-ws @Endpoint annotation together with
jetty as webserver) and then just launch / shutdown that webservice while
testing the Producer (e.g. at JUnit @BeforeClass & @AfterClass). I've done this
once for one of my Apps and will hopfully add/change this here once I get
sometimes to do that but currently I'm much more than busy :-( that's the idea
would be to remove any invocation of the site http://www.webservicex.net.
- IMHO the current behaviour to force users to use dedicated WebServiceTemplate
objects just because a timeout option has been used is an unnecessary
limitation and not nice at all. I did mention this by my previous comment about
how we could easily deal with this, just proactively clear out (reset to 0) any
possibly set timeout on the MessageSender *if* no timeout option is being given
by the passed URI. Then another invocation using the same WebServiceTemplate
with a given timeout would then set the timeout again to whatever value it has
been told to be inside URI. But for this you would then need to put the
prepareMessageSenders() call back to where it was before (not a static single
call inside the constructor but dynamically by each invocation of the process()
method through camel routing engine.)
- And another point which was *my own BAD* for CAMEL-4998: the default value of
the timeout flag in SpringWebserviceConfiguration should better be *0* and not
*-1* as that's what both the jdk and commons-httpclient API's semantics
understand/provide, however changing this is really trivial and it would not
cause any side effects.
> 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
