ActiveMQ and JRun4's JMS collision

posted: 18 Sep 2013

It seems that the latest versions of Apache ActiveMQ (5.*) are now using JMS 1.1 rather than the earlier (4.*) versions that used JMS 1.0. This means that when enabling ActiveMQ 5.* in our CF applications, we were getting some inconsistent behavior when trying to send messages, with the page either halting or receiving Java error messages relating to the ActiveMQ sendMessage() method. The issue seemed to revolve around the fact that ActiveMQ relies on the javax.jms package and if it was finding an older version of this package (from a previous incompatible version of JMS) things go south. However, if you can force JRun to load the 1.1 javax.jms package before the native JRun version, you can get things to work.

You can do this by first creating a new directory in { application.home }/lib/ named after the version of ActiveMQ I was using, eg { application.home }/lib/activemq520, and putting the Active MQ jar in there (use the jar file found in the root of the ActiveMQ install, usually called activemq-all-5.?.?.jar. If you then create a custom jvm-config for any JRun/CF instance that you need to work with JMS 1.1 you can ensure that the right version of the javax.jms package is loaded.

Simply duplicate the existing jvm.config file found in { application.home }/bin and call it something like jvm-amq520.config and edit the line that starts 'java.class.path'. What I've found to work is to simply ensure that the activemq folder we created above is listed BEFORE the /lib folder (I think it's the jrun.jar file that we need to beat to loading).

My java.class.path now ends:


Then when running JRun specify the new config jrun -config jvm-amq520.config -start default Or on Windows, to install the instance as a Windows service jrunsvc -install default CFDefault CFDefault CFDefault -config jvm-amq52.config you can swap out the 'default' for the name of the instance and CFDefault for the text you want to display in the Windows services manager.


Python/Django error more meaningful on 2.7 than 3.

posted: 18 Sep 2013

Had a strange one today trying to start one of my Django sites after manually (i.e. not using adding a new app. I had added the and the but forgot the Trying to start that on Django under Python 3, I got this rather obscure (at least to me) error

AttributeError: 'module' object has no attribute '__file__'

Now that had me a little confused, until I tried running the exact same application using Python 2.7 and the error came back

ImportError: No module named tricurve

tricurve, being the name of the application I'd added was a great big clue here. I realized that I had simply not indicated that I wanted Python to consider tricurve as a module, which is done by creating a file. After doing that, it started fine under Python 2.7 and then, after switching back to Python 3, it started fine too.