Hi Thanks for sharing this with the community.
On Wed, Oct 5, 2011 at 11:24 AM, bvahdat <babak.vah...@swissonline.ch> wrote: > Hi, > > in my previous post in August by this thread I promised to give a status > update how the things worked out using camel-spring-ws to implement a > webservice > client calling a webservice (through HTTP-Proxy to Extranet) expecting a > strong authentication (client-certificate). All in one, it simply worked > like a charm! > > As I feel myself owing a lot to the apache camel community, I would like to > give some hints to other community user about the way I went for it but by > no > means this should be understood as the only and the best way to go for it. > Please also apologize me for my poor English. > > At the end of the day, it came out that *no* extra spring > customization/configuration was required concerning the > HTTP-Connection-Setup (see David Valeri > comments on this thread), as the default implementation of > org.springframework.ws.transport.WebServiceMessageSender invoked (that's > org.springframework.ws.transport.http.HttpUrlConnectionMessageSender) > was simply good enough for a succesful SSL-Handshake with the server. The > reason for that is pretty simple as it uses > > java.net.URLConnection.openConnection(); > > which is smart enough to return a matching/meaningful extension of > java.net.URLConnection under SUN-JDK, that's > sun.net.www.protocol.https.DelegateHttpsURLConnection > which is capable of initiating the SSL-Handshake. See also this screenshot > http://camel.465427.n5.nabble.com/file/n4872087/debug.jpeg debug.jpeg > > As the camel-spring-ws doesn't yet support the camel's own TLS-Configuration > (see Claus comments on this thread), I went for plain old java style to > configure > the keystore/truststore etc. For that I used the spring's own SpEL in my > setup, something like this: > > <bean > class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"> > <property name="location" value="file:config/egris.properties" > /> > </bean> > > <bean id="systemPropertiesSetter" > class="org.springframework.beans.factory.config.MethodInvokingFactoryBean"> > <property name="targetObject" value="#{systemProperties}" /> > <property name="targetMethod" value="putAll" /> > <property name="arguments"> > <util:properties> > <prop > key="https.proxyHost">${https.proxyHost}</prop> > <prop > key="https.proxyPort">${https.proxyPort}</prop> > <prop > key="javax.net.debug">${javax.net.debug}</prop> > <prop > key="javax.net.ssl.keyStore">${javax.net.ssl.keyStore}</prop> > <prop > key="javax.net.ssl.keyStorePassword">${javax.net.ssl.keyStorePassword}</prop> > <prop > key="javax.net.ssl.trustStore">${javax.net.ssl.trustStore}</prop> > <prop > key="javax.net.ssl.trustStorePassword">${javax.net.ssl.trustStorePassword}</prop> > ... > ... > </util:properties> > </property> > </bean> > > The application is a one-single-shot-application, by that I mean that it > get's kicked-off by some external processes causing it to assemble the input > and make > the call and finally shutdown the JVM. For this purpose I made use of > camel's spring-Main [1], however as I had to shutdown the VM in *all* cases, > I did stop the > camel context in a *finally* block, as otherwise if something goes wrong > while calling the webservice through ProducerTemplate the Exception catched > through camel > itself (while routing) will be rethrown wrapped by CamelExecutionException > to the caller (that's me). On the other hand as there're camel's own > ThreadPools created > at runtime through JDK-API containing *non-daemon-threads* the process will > simply *hang*. To make it clear here some code: > > void start() throws Exception { > main.start(); // this main is org.apache.camel.spring.Main > template = main.getApplicationContext().getBean("producerTemplate", > ProducerTemplate.class); > } > > Object request(final EgrisServiceChoice serviceChoice, final Object > payload) { > return template.requestBodyAndHeader(EGRIS_ROUTE_URI, payload, > SERVICE_CHOICE_HEADER_NAME, serviceChoice); > } > > void stop() throws Exception { > main.stop(); > } > > public static void main(final String[] args) throws Exception { > ... > ... > final Main main = new Main(); // this Main is the application's own > Main wrapping org.apache.camel.spring.Main, having the 3 methods above > main.start(); > ... > ... > boolean failed = false; > try { > final Object response = main.request(serviceChoice, request); > final String convertedResponse = > main.getCamelContext().getTypeConverter().mandatoryConvertTo(String.class, > response); > LOGGER.info("received the terravis webservice response: {}", > convertedResponse); > } catch (final Exception exp) { > LOGGER.error("invocation of the terravis webservice failed: " + > exp.getMessage(), exp); > failed = true; > } finally { > main.stop(); > System.exit(failed ? 1 : 0); > } > > // not reached > } > > As you see stopping of the camel context is to be done in a *finally* block > for the reason explained before. > > I hope these explanations will be helpful for other community users willing > to use camel-spring-ws. > > [1] > http://camel.apache.org/running-camel-standalone-and-have-it-keep-running.html > > Regards, Babak > PS: I also thank David/Claus alot for their help. > PS2: The application was developed under SUN/Oracle JDK1.6 *and* > successfully deployed under IBM JDK1.6. > PS3: This information could be also important regarding TLS/SSL security > hole: > http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-176330.html > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/need-some-advice-on-cxf-or-spring-ws-tp4643001p4872087.html > Sent from the Camel - Users mailing list archive at Nabble.com. > -- Claus Ibsen ----------------- FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
