{"id":697,"date":"2011-11-11T13:16:00","date_gmt":"2011-11-11T13:16:00","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/2012\/10\/web-service-learnings-with-apache-cxf.html"},"modified":"2012-10-21T20:41:15","modified_gmt":"2012-10-21T20:41:15","slug":"web-service-learnings-with-apache-cxf","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2011\/11\/web-service-learnings-with-apache-cxf.html","title":{"rendered":"Web-service learnings with Apache CXF"},"content":{"rendered":"
In my last couple of projects I worked with web-services, creating them at some places and consuming them at others. I felt that the standard tasks like creating a client, creating a web service etc are quite straight forward and there are enough resources if you get stuck. But with web services, it is some trivial task that can take a lot of your time and you feel quite frustrated when you can not get that simple thing right.<\/p>\n

Logging<\/span><\/p>\n

In one of the projects, we created web-services using Apache CXF<\/a> and things were working fine. There was just one issue Apache CXF<\/a> uses java.util logger for logging and used to print all sorts of logs. Our application was using Log4J, so task was simple make use of Log4J for Cxf and control logging.<\/p>\n

Configuring the logger to use Log4J is a starightfoward task as mentioned on Apache CXF site<\/a>, here is what the page says:<\/p>\n

\n

Add the file META-INF\/cxf\/org.apache.cxf.Logger<\/tt> to the classpath and make sure it contains the following content: org.apache.cxf.common.logging.Log4jLogger<\/span><\/p>\n<\/blockquote>\n

Simple you need add a file to the META-INF directory and it will be done. We were having a maven project to generate war, so I created the file in the META-INF folder that gets generated for the war i.e. at src\/main\/webapp\/META-INF.<\/p>\n

Now, the file is there but the logging was still out of control, CXF was still using java logger. I spent some more time on it to figure out what I have done wrong. Some more effort was required to realize that I have missed and important instruction \u201cin the classpath\u201c. The META-INF folder that gets generated besides the WEB-INF is not in the classpath and a META-INF folder is required in the classes folder of the war.

<\/div> <\/div><\/p>\n

After words looking back at this issue, it was silly for me to miss the classpath part, but also I could not understand why the CXF guys choose the META-INF folder for their configuration files. META-INF is there on Java platform for services and class loaders. It becomes quite ambiguous when frameworks start using it for their configurations and then there are multiple folders to play around, which can make things quite unclear.<\/p>\n

Soap Handlers<\/span><\/p>\n

At another place we had a requirement where we need to intercept the incoming \/ outgoing soap requests and then do something with it. Apache CXF provides interceptors<\/a> that can be used to accomplish this task. You can have some inbound and out bound and they will do as asked. But we were using the jaxws implementation that gets shipped with java. Not intending to shift our existing clients to CXF , as we were having quite a few clients, it took us quite some time to figure it out how you can accomplish this with the jaxws.<\/p>\n

Basically, according to the JAX-WS specification you can have some SoapHandler<\/a>s that can be configured with the client. The handler will be called every time there is a SOAP message exchange. In the handler you can determine if this is an in-bound message or an out-bound and then do your logic. These are the steps required to configure a handler :<\/p>\n

Create a class extending the SoapHandler interface and implement the handle message method:<\/p>\n

class CustomHandler implements SOAPHandler<SOAPMessageContext>{\r\n \/\/ TODO: implement other methods\r\n public boolean handleMessage(SOAPMessageContext context) {\r\n  \/\/ Check for message status\r\n  Boolean outboundProperty = (Boolean)\r\n   context.get(MessageContext.MESSAGE_OUTBOUND_PROPERTY);\r\n  if (null == outboundProperty || !outboundProperty) {\r\n      log.debug(\"not an outbound message\");\r\n      return true;\r\n  }\r\n }\r\n}\r\n<\/pre>\n
Handlers are like servlet filters. They are in a chain and gets called one by one. So we need to create a XML file in which we can configure all the handlers we want.<\/p>\n
<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"yes\"?>\r\n<javaee:handler-chains\r\n     xmlns:javaee=\"http:\/\/java.sun.com\/xml\/ns\/javaee\"\r\n     xmlns:xsd=\"http:\/\/www.w3.org\/2001\/XMLSchema\">\r\n  <javaee:handler-chain>\r\n    <javaee:handler>\r\n      <javaee:handler-class>pkg.CustomHandler<\/javaee:handler-class>\r\n    <\/javaee:handler>\r\n  <\/javaee:handler-chain>\r\n<\/javaee:handler-chains>\r\n<\/pre>\n
Also the configuration file needs to be in the classpath as this will be imported in the web service clients that we create. After this is done, we need to enable this chain of handlers on a web service client.<\/p>\n
@WebServiceClient(.....)\r\n@HandlerChain(file=\"handlerFile.xml\")\r\npublic class SampleServiceImpl extends Service{\r\n}\r\n<\/pre>\n
The handler concept is from the jaxws specification and would work on all of its implementations like metro, CXF etc. <\/p>\n
Reference: <\/i><\/strong>Web-service learnings<\/a> from our JCG partner<\/a>  Rahul Sharma<\/a> at the “The road so far\u2026.” blog<\/a>.<\/p>\n
Related Articles :<\/i><\/strong><\/div>\n