Unable to locate Spring NamespaceHandler for XML schema namespace [http://camel.apache.org/schema/spring]

Problem:
Exception in thread "main" org.springframework.beans.factory.parsing.BeanDefinitionParsingException: Configuration problem: Unable to locate Spring NamespaceHandler for XML schema namespace [http://camel.apache.org/schema/spring]
Offending resource: class path resource [camel-context.xml]


Solution:
Very simple: Add camel-spring.jar to classpath

How to access OracleConnection in Tomcat server

If you ever want to access underlying Oracle Connection in an application deployed in Tomcat server, you can use the following simple code.

try{
 java.sql.Connection connection = ConnectionManager.getConnection();
 OracleConnection ocn = connection.unwrap( OracleConnection.class );       
 XMLType xmlReq = new XMLType(ocn, rxml);
 ...
 ...
 ...

}catch(Exception e){
 e.printStackTrace();
}


For more documentation, please read http://docs.oracle.com/javase/6/docs/api/java/sql/Wrapper.html#unwrap(java.lang.Class)

Hope this tip is useful to you.

How to access oracle.jdbc.OracleCallableStatement object in JBoss or Tomcat servers

Though it may not be advisable to directly work on the underlying vendor specific API such as oracle.jdbc.OracleCallableStatement, how would do you access it when situation arises.

Use the below snippet for a JBoss deployed application:
public static OracleCallableStatement getOracleCallableStatement(java.sql.CallableStatement callableStatement) throws SQLException {
     OracleCallableStatement ocs = null;
if(callableStatement instanceof org.jboss.resource.adapter.jdbc.WrappedCallableStatement) {
            org.jboss.resource.adapter.jdbc.WrappedCallableStatement wc = (org.jboss.resource.adapter.jdbc.WrappedCallableStatement) callableStatement;
            Statement stmt = wc.getUnderlyingStatement();
            ocs = (OracleCallableStatement) stmt;
        }
       return ocs;
}

For java doc, please read http://docs.jboss.org/jbossas/javadoc/4.0.2/org/jboss/resource/adapter/jdbc/WrappedCallableStatement.html


Use the below snippet for a Tomcat deployed application:

public static OracleCallableStatement getOracleCallableStatement(java.sql.CallableStatement callableStatement) throws SQLException {
     OracleCallableStatement ocs = null;

if( callableStatement instanceof org.apache.tomcat.dbcp.dbcp.DelegatingCallableStatement) {
            org.apache.tomcat.dbcp.dbcp.DelegatingCallableStatement dcs = (org.apache.tomcat.dbcp.dbcp.DelegatingCallableStatement) callableStatement;
            ocs = (OracleCallableStatement)dcs.getInnermostDelegate();
        } 

       return ocs;

}

Hope this is useful. Let me know if comments.

Enable access log in JBoss application server

Go to %JBOSS_HOME%\server\default\deploy\jboss-web.deployer folder and you will find server.xml. The Access logger is disabled by default. Just un-comment the access logger section and restart the JBoss application server. Rest is taken care.

Here is the Access logger configuration.
<Valve className="org.apache.catalina.valves.FastCommonAccessLogValve" prefix="localhost_access_log." suffix=".log" pattern="common" directory="${jboss.server.home.dir}/log" resolveHosts="false" />
The access log file will be created with the name - "localhost_access_log.2014-02-06" . The file is rotated every day. However, if required, you can modify the file name by reconfiguring. Generally, I would prefer to name it like node1_hostname_access.log where hostname is the name of the server in which JBoss is running. This will allow me to process and analyze several log files in a cluster environment without any ambiguity.

As other standard servers support, JBoss also supports two log format patterns - 1) common and 2) combined.

Apart from common and combined, you can also customize the log format as you wish. I have customized to my requirement as follows: -
 
<Valve className="org.apache.catalina.valves.AccessLogValve"
                prefix="node1_hostname_access." suffix=".log"
                pattern="%a %A %u %t %r %s %T %b %S" directory="${jboss.server.home.dir}/log"
                resolveHosts="false" />

Please read https://docs.jboss.org/jbossweb/latest/config/valve.html for more information on the parameters.

See below sample access log generated.

127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/ HTTP/1.1 304 0.007 - -
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/applet.jsp HTTP/1.1 200 0.041 444 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/ServerInfo.jsp HTTP/1.1 200 0.060 4226 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/css/jboss.css HTTP/1.1 304 0.000 - 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/images/logo.gif HTTP/1.1 304 0.000 - 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] POST /web-console/Invoker HTTP/1.1 200 0.439 2245739 93300E3B983D53F8BE5FB39901E48B6B
127.0.0.1 10.xx.xx.xx- [06/Feb/2014:16:01:07 +0530] GET /web-console/%5bLorg/jboss/console/manager/interfaces/ResourceTreeNode.class; HTTP/1.1 404 0.001 1177 93300E3B983D53F8BE5FB39901E48B6B


Hope you liked the tip.

HTTP 500 error and Chunked encoding in OSB/WebLogic

Till recently, there was a strange issue seen in peak time with my production WebLogic Server. I have a bunch of Web Services deployed in CXF in WebLogic server. The message flow is as below: -

External Load balancer --> OSB --> External Load balancer --> (CXF in) Web Logic


While up to 95 to 98% of the requests sent to WebLogic had been processed successfully, the remaining requests were timed out in 30 seconds by WebLogic server. When I looked at the access log generated in the WebLogic server, all timed out requests had recorded with HTTP status code 500.  It took a while to understand, isolate and resolve the issue.

I did a thread dump analysis and saw several hogging threads with a kind of trace given below:


"[ACTIVE] ExecuteThread: '43' for queue: 'weblogic.kernel.Default (self-tuning)'" RUNNABLE native
         
                java.net.SocketInputStream.socketRead0(Native Method)
         
                java.net.SocketInputStream.read(SocketInputStream.java:129)
         
                weblogic.servlet.internal.PostInputStream.read(PostInputStream.java:142)
         
                weblogic.utils.http.HttpChunkInputStream.readChunkSize(HttpChunkInputStream.java:115)
         
                weblogic.utils.http.HttpChunkInputStream.initChunk(HttpChunkInputStream.java:74)
         
                weblogic.utils.http.HttpChunkInputStream.skip(HttpChunkInputStream.java:203)
         
                weblogic.utils.http.HttpChunkInputStream.skipAllChunk(HttpChunkInputStream.java:378)
         
                weblogic.servlet.internal.ServletInputStreamImpl.ensureChunkedConsumed(ServletInputStreamImpl.java:35)
         
                weblogic.servlet.internal.ServletRequestImpl.skipUnreadBody(ServletRequestImpl.java:194)
         
                weblogic.servlet.internal.ServletRequestImpl.reset(ServletRequestImpl.java:152)
         
                weblogic.servlet.internal.MuxableSocketHTTP.requeue(MuxableSocketHTTP.java:195)
         
                weblogic.servlet.internal.VirtualConnection.requeue(VirtualConnection.java:329)
         
                weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1538)
         
                weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1455)
         
                weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
         
                weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
After further investigation, I found that the WebLogic server was not receiving the message within the default POST TIMEOUT (30 seconds) configured in the WebLogic server. Increasing the time out value to 45 or 60 seconds did not help. It only aggravated the performance issue.

Let's look at how the issue was resolved. When you define a business service in Oracle Service Bus (OSB), you would have seen a parameter namely "Use Chunked Streaming Mode" under "HTTP Transport Configuration" section. The default value was configured as "Enabled". Apparently, the load balancer was not able to handle requests with chuncked encoding in peak time. It was unable to transmit the request message to the WebLogic server within the configured post timeout period. It can be validated against the thread dump shown above. After changing the value from "Enabled" to "Disabled", the 500 error has been eliminated permanently and now the server is in good health.

Thanks for reading this post and hope you liked the tip. Please feel free to post your comment here.