How to get MQ JMS Calls log

If you want to enable trace log for Websphere Java MQ and JMS Calls then you need to add following properties while starting tomcat/WAS/java program


-Djava.library.path="C:\WAS_MQ_LIB" It should be the path to the directory where mq related jars are available

-DMQJMS_TRACE_LEVEL="base" – it will do max logging

-DMQJMS_TRACE_DIR="c:\LOGS" – path to the directory where log should be written to

Ibatis error: Error parsing XPath '/sqlMap/insert'. Cause: java.util.NoSuchElementException

If IBatis is throwing following exception then apart from usual suspects of correct dtd declaration in sql-map-config xml and sql-map xml files, one should also look at the insert sql definition in sql-map xml.

com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: java.lang.RuntimeException: Error parsing XPath '/sqlMapConfig/sqlMap'. Cause: com.ibatis.common.xml.NodeletException: Error parsing XML. Cause: java.lang.RuntimeException: Error parsing XPath '/sqlMap/insert'. Cause: java.util.NoSuchElementException

I had something like this in my insert query xml definition:
INSERT INTO TEST_T (ACCT_ID) VALUES (#acctId)

above mentioned sql statement throws com.ibatis.common.xml.NodeletException which is difficult to figure out.

In my case, error is due to not having closing hash (#) with acctId

If i change the insert statement to following then things work again, notice the closing # in #acctId#

INSERT INTO TEST_T (ACCT_ID) VALUES (#acctId#)

Hope that this is of some use to others who get this error.

150 is the limit of human brain!

This article from July/August 2009 issue of IEEE Security & Privacy states that based on research, it has been found that 150 is the limit of human brain to recognize other people, personally.

It has been this way forever and military formations also follow this rule and so do other tribes.

More can be read here.

How to fix Spring and MQ issue of Failed to convert property value of type [javax.naming.Reference] to required type [javax.jms.ConnectionFactory]

I ran into this exception and had to waste some hours to fix it. I was using Rational Application Developer 6 with Websphere MQ 5.3 to run a command line client. It should be valid for even higher versions of RAD and WMQ.

Exception is

org.springframework.beans.TypeMismatchException: Failed to convert property value of type [javax.naming.Reference] to required type [javax.jms.ConnectionFactory] for property 'targetConnectionFactory';

I hope that following will help others who run into this issue.

Steps you can take to solve this are:

1) Make sure that you have following jars in classpath:

* com.ibm.mq.jar
* com.ibm.mqbind.jar
* com.ibm.mqjms.jar
* ecutils.jar
* j2ee.jar
* messaging.jar
* messagingClient.jar
* messagingImpl.jar
* namingclient.jar

2) If above is there in classpath but you are still getting this error then check if you have conflicting version of jms related classes.

Sometimes, we have 2 different versions of jms.jar or jms related classes.

Make sure that you have right version of classes.

3) If you suspect class loading issue then use -verbose as a vm argument to see the classloading details.

See following article for RAD and JMS for more details.

Using Java to Crack Office 2007

Using Java to Crack Office 2007 is a good article by Ted Neward - it shows how you can read word 2007 using plain java - thanks to new OOXML

Finding out major mail servers of the world

This article is great about how to identify the mail servers, out there in the wild.

What is interesting is to look at mail server responses...

Physiological Basis of Yoga

Yoga is known to have done wonders for people. This article goes into some details to explain the physiological basis for this.

Code Quality: Coupling, Afferent and Efferent and Code Quality

All Software Projects deviate from their original design, as the time goes by. This is specially true
as code base gets bigger and new developers join in.

Maintaining the intention of design and keep things manageable, becomes tougher and tougher.

To handle this kind of situation, we need some support from Tools to properly understand
the coupling of code, their complexity and their test coverage. Without this information,
it is nearly impossible to know the cost of change in system.

Thankfully, we have JDepend which can help us deal with these kind of issues. It gives
us a measure of afferent (how many packages depend on you) and efferent coupling (how many
packages you depend on), Abstactedness, Instability.

Do read this article to know more about it.

Good news is that you can integrate this into your eclipse workspace too, via an eclipse plugin.