We Keep Coding

Apache Camel Environment Property file

I am implementing application for job scheduling in apache camel. I am able to read property config data inside camel context xml using spring propertyplaceholder.
How can I pass commandline argument like sit, dev, uat, prod to read config file of specific environment. like app.dev.properties to the camel xml file.
Currently I hardcoded dev in below configuration.
<bean
class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
<property name="location">
<value>Application.dev.properties</value>
</property>
</bean>
and accessing properties in Apache camel as below
<route id="GET-XML-DATA">
<from uri="direct:getxmldata"></from>
<to uri="http://{{appIPAddress}}:{{AppPort}}/getData" />
</route>
I am trying to implement completely xml and less java code

You can use spring beans profile where you can define same bean for different environment. This way you would be able to pick environment specific beans

SOAP UI doesnt generate wsdl-interface

I am trying to test my soap web service by SOAP-UI, Also I use Spring-ws and Java.
I point to my wsdl file in spring configuration like this:
<bean id="myservice" class="org.springframework.ws.wsdl.wsdl11.SimpleWsdl11Definition">
<constructor-arg value="/WEB-INF/wsdl/myservice.wsdl"/>
</bean>
Then in the SOAP UI I locate this wsdl file, but it does not create and WSDL-interface that I can work with to create requests.
But If I use the exactly same xsd but dynamically create the wsdl file than SOAP UI creates the wsdl interface fine:
<sws:dynamic-wsdl id="myservice"
portTypeName="MyService"
locationUri="/myService"
targetNamespace="http://mypath">
<sws:xsd location="/mypath.xsd"/>
</sws:dynamic-wsdl>
What am I missing? I need modify my wsdl file and not work directly with spring auto generated wsdl.

Validate SOAP message against WSDL

Just like validating an XML file against an XML Schema Definition in Java is there a way to validate an XML file that contains a SOAP Envelope against a WSDL file?

Some web service containers provide this functionality. JBoss 3.0.1+ does this with the #SchemaValidation annotation:
http://community.jboss.org/wiki/JBossWS-NativeUserGuide#SchemaValidation

If you are using Spring-WS, this can be done by using an interceptor along these lines:
<sws:interceptors>
<sws:payloadRoot namespaceUri="...">
<bean id="validatingInterceptor"
class="org.springframework.ws.soap.server.endpoint.interceptor.PayloadValidatingInterceptor">
<property name="schema" value="classpath:/wsdl/schema.xsd" />
<property name="validateRequest" value="true" />
<property name="validateResponse" value="true" />
</bean>
</sws:payloadRoot>
</sws:interceptors>
With CXF, here is an approach:
http://cxf.apache.org/faq.html#FAQ-HowcanIturnonschemavalidationforjaxwsendpoint%3F

There is a tool developed by Ivan Krivyakov which validates the req or resp XMLs based on the WSDL and / or XSD provided. The tool is available at http://www.codeproject.com/Articles/182406/Validating-SOAP-Message-against-WSDL (requires you to create a login though.)

I don't know simple way. In our project we just copy and paste element from WSDL to XSD file. You can write an util class which will make this work instead of you.

passwordCallback in CXF

I develop a webservice client for an existing webservice. I am using Apache CXF 2.2. The service requires security with Username and plain text password, which I configured like this:
<bean id="myPasswordCallback"
class="com.kraemer_imd.mobilized.m2m_adapter.ClientPasswordCallback"/>
<jaxws:client id="m2mClientService"
serviceClass="de.vodafone.easypu.ws.EasyPUOrderServicePortType"
address="http://m2m.vodafone.de/speasy/services/EasyPUOrderService"
bindingId="http://www.w3.org/2003/05/soap/bindings/HTTP/">
<jaxws:outInterceptors>
<bean class="org.apache.cxf.ws.security.wss4j.WSS4JOutInterceptor">
<constructor-arg>
<map>
<entry key="action" value="UsernameToken Timestamp"/>
<entry key="passwordType" value="PasswordText"/>
<entry key="user" value="myusername"/>
<entry key="passwordCallbackRef">
<ref bean="myPasswordCallback"/>
</entry>
</map>
</constructor-arg>
</bean>
</jaxws:outInterceptors>
</jaxws:client>
That works quite well. But I did not understand why I have to provide the password via a callback handler instead of just providing it via configuration. The documentation says it is for security reasons, but I don´t see why this should be more secure to have a callback handler that reads it from a property file (or worse has it hard coded in the callback).
So, could somebody explain this to me? Maybe the callback is intended for some magic stuff that I missed..
Thanks
Michel

The password callback is provided by Apache CXF as a mechanism for the client application to retrieve the credentials for the targeted webservice, which at runtime is likely to be stored in the database, configuration fiels, LDAP or some other store. This callback hook provides the flexibility to the application to retrieve the credentials from application specific configuration.

If password is stored in clear text in the configuration then this approach may not give you any extra security.
However having password stored as clear text in some configuration may have some security issues as there can be folks that may need access to this configuration and will be able to hold of password although it may not have been intended to.
Better is to store the encrypted password in the configuration. In this case, you need some code that will decrypt this password before it's use. Password callback will come to rescue in this scenario.

CXF server-side logging to a table

In CXF, you can enable logging using this:
<cxf:bus>
<cxf:features>
<cxf:logging/>
</cxf:features>
</cxf:bus>
Source: http://cxf.apache.org/docs/configuration.html
Everything seems to go to files or console and can be configured using Log4j as well it seems.
My question is, how do you enable logging on server side so that you can intercept these raw requests and responses and store them in a table in the database along with other application specific information related to the service call.
This is all for server-side service implementation class.

The example you quoted was the simplest possible config to do basic logging. If you look at the example right before, you can see a slightly more expanded approach to logging interceptors:
<cxf:bus>
<cxf:inInterceptors>
<ref bean="logInbound"/>
</cxf:inInterceptors>
<cxf:outInterceptors>
<ref bean="logOutbound"/>
</cxf:outInterceptors>
<cxf:inFaultInterceptors>
<ref bean="logOutbound"/>
</cxf:inFaultInterceptors>
</cxf:bus>
Here, the logInbound, logOutbound and logOutbound beans are any implementation of CXF's interceptor interface. You can implement your own interceptor beans to do any type of logging you choose, including database logging.