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.


Update: http POSTs in ColdFusion and Apache Common

posted: 30 Jun 2011

I mentioned in this post that I had been having issues with cfhttp and uploading files. Well, the solution that I proposed in that post used a String object, into which the file contents were read, before assembling the response. This works well, but it does impose the overhead that the file is read into memory before being passed to the destination. This obviously starts to cause problems when we get large files being uploaded and so I started looking for another alternative.

I'm not sure what underpins the implementation of cfhttp in ColdFusion (I presumed in was Apache commons httpclient) but I thought I'd give that a go regardless, since it's already available to CF as it comes already inside the cfusion/libs directory. The 3.1 version has now been superseded, but I managed to locate the Javadocs and some example code, so thought I'd give it a try.

Here's what I came up with:

<cfset objFile = CreateObject("java", "")>
<cfset objFile.init(filepathandname)>
<cfset uploadUrl = request.rhino.getLocal("docapiurl", true)>

<cfset commonsHttp = CreateObject("java", "org.apache.commons.httpclient.HttpClient")>

<cfset commonsHttpPost = CreateObject("java", "org.apache.commons.httpclient.methods.PostMethod")>
<cfset commonsHttpPost.init(uploadUrl)>

<cfset commonsHttpFilePart = CreateObject("java", "org.apache.commons.httpclient.methods.multipart.FilePart")>
<cfset fileName = GetFileFromPath(filepathandname)>
<cfset commonsHttpFilePart.init("file", filename, objFile)>

<cfset commonsHttpMeta = CreateObject("java", "org.apache.commons.httpclient.methods.multipart.StringPart")>
<cfset commonsHttpMeta.init("meta", xmlString)>

<cfset commonsHttpAction = CreateObject("java", "org.apache.commons.httpclient.methods.multipart.StringPart")>
<cfset commonsHttpAction.init("action", "upload")>

<cfset httpParts = [commonsHttpFilePart, commonsHttpMeta, commonsHttpAction]>
<cfset commonsHttpMultipartRequest = CreateObject("java", "org.apache.commons.httpclient.methods.multipart.MultipartRequestEntity")>
<cfset commonsHttpMultipartRequest.init(httpParts, commonsHttpPost.getParams())>
<cfset commonsHttpPost.setRequestEntity(commonsHttpMultipartRequest)>

<cfset commonsHttp.getHttpConnectionManager().getParams().setConnectionTimeout(5000)>
<cfset status = commonsHttp.executeMethod(commonsHttpPost)>
<cfset uploadResponse = commonsHttpPost.getResponseBodyAsString()>

It seems to be working well, so in case you run in to cfhttp problems, give some Java a try.


Samples: (


Linux and Windows

posted: 04 Jun 2009

It's no secret that I've been sitting on the Linux fence for a few years, never getting much further than installing a copy of Linux, only to be halted by requirements to recompile the kernel or learn a bunch of command line wizardry to open a file. However, with our new house and the almost endless scope for networking niceties, I have looked once more to the open source. And this time, I am finally finding my feet. Thinking back to the days when I was 'learning' Windows, I would spend hours installing, configuring, breaking and reinstalling 98, ME, 2k, XP... now it's happening all over again, but with Linux. Although, this time, the web is there to help and I have a goal in mind.

My end game is to create a Windows domain, web/application, database and DNS server. To what end, I'm not completely clear, but at the heart of it, is to be able to host small web applications from my own network and browse them from 'the outside'. And all this, to be done on using only open source applications and a small footprint, low powered Mini-ITX PC board. And it's going pretty well.

Recent achievements have got Fedora Core 4 installed and Samba set up with basic Primary Domain Controller functionality and my new NAS (Buffalo nkstation 2Gb) mounted for file storage. The next phase is to install MySQL with the data on the NAS and then Apache/JBoss/Railo for application development.

I'll keep you posted, on how that all goes, but let me finish by saying that I am now, officially a Linux fan. Not yet a -phile but I'm working on that.


File upload progress and CF

posted: 18 Mar 2008

I'm working on a video project at work, where we need to provide visual feedback on a file upload. You know the sort, fill in the form, pick your file, hit submit and watch the progress bar tell you how much has been uploaded.

Well my initial thought was that ColdFusion would be able to do this, submit to a hidden iframe and then monitor the files size, however, it appears CF won't even start to process the script until the entire request, file and all, has been received. So by the time you can do anything scripty, the process is already complete. Even if the script doesn't use the file, it gets it ready to process just in case.

So I turned my gaze to Java, CF being Java meant I could maybe sit a jsp alongside my CF pages, and I found FileUpload from those great guys at the Apache Foundation. The latest incarnation (1.2 I think) of FileUpload has the ability to watch the upload progress. You basically register an event handler class to the update() method of FileUpload.

So I got my Java books out and went to work on revising inner classes. I now have two jsp pages, one that accepts the form with an inner class that writes the percentage complete, and other status' to an application variable, and a second that provides a monitor on this status.

On submit of the form, JavaScript rewrites the form submission, hides the submit button, reveals the progress bar, creates a hidden iframe and submits the form to it. It then sets up an asynchronous XHR to watch it's progress. The monitor jsp file feeds back the progress and the page updates a set of divs that make up the progress bar. Once the file is uploaded a 'new' status is returned to the browser and the page redirects to a static 'success' page.

I am thinking about posting an example of the code, once I've ironed out any wrinkles.


Watch lists trial

posted: 27 Dec 2007

I was going through my inbox tonight when I realised that I am keeping a lot of emails, just because they have links to stuff that I want to look at. They are resources that I might not necessarily want to keep in but I don't want clogging my inbox and I don't yet want to delete. So I have created a feature on bluemini called watchlist. It's basically a link list of things that I want to look at, but as yet haven't had the time to. I don't know how it will progress. Whether I actually use it, I don't know. If I do, then I'll need to figure out some kind of workflow for those links once I've vetted them but exactly what that might be, I don't know.

For now, I have a bookmark shortcut that posts the site url and title to a form that I can edit and send to my database. I also output them to a list if you're interested in seeing the list (sort of) so far. I'll keep you posted how it goes.


Eclipse and Subversion

posted: 26 Dec 2007

I've used the Eclipse IDE for ColdFusion development for a few years in the guise of CFEclipse but in the last year, my invovlement in Java, particularly for web applications, has increased and with Eclipse installed on my desktop already, it seemed a perfect fit to carry on using the same familiar IDE for the Java development as well.

However, we are a big user of Subversion for our version control and I found that I was suffering predictable but unhelpful functionality from the Java build process in Eclipse. The basic problem is that during compilation, particularly a full build, the IDE would strip out the build output folder and then replace it with the freshly comiled contents of my src directory. This has one major flaw when using Subversion; Subversion uses a folder (.svn) and sub folders/files to control the version control information for the contents of that folder, in particular the url into the repository where these files live. During a rebuild, this information was being replaced with the Subversion information from the src folder, including the repository location of the src files. Trying to commit the compiled classes to Subversion (I know, probably not the best thing to do) would result in my compiled classes being pushed at the Subversioned src folder in the repository, this would break Subversion and I couldn't commit anything to the repository.

I Googled this problem and I found one posting about excluding the subversion files during the compilation but no help in how this could be done. But this morning I figured it out and thought I would post it here for my own use and to help anyone else with a similar problem.

The settings can be done either local to a project or globally to the IDE (I chose IDE wide). To do this, select Window from the main IDE menu and then 'Preferences...'. In the left menu expand the 'Java' node and then expand the 'Compiler' node. Now pick on the 'Building' node, this brings up the Building preferences in the main pane and scroll down to the 'Output Folder' section. I modified two settings to make this work for me:

1. Uncheck the 'scrub output folders when cleaning projects', otherwise your .svn and other control files will be removed 2. Enter two (extra) terms to the 'Filtered Resources' text box. '*.svn*, *svn/'. This should stop any svn folders or files from being copied.

Then hit Apply or OK and rebuild your project.


Image Function

posted: 23 Nov 2007

I've been writing these items the same way for about 4 years, always by email, using a schedule on the site to pick up, parse and store different items for display in different parts of the site.

For the first few years I was able to post images as attachments to the emails. These were then saved and at render time the file system was checked for matching files to show.

Now, I am refactoring to put attachments into a database table (I know, too long coming). One thing I really want is the ability to add images to the homepage.

So here goes a test post!


What's in a name

posted: 22 Aug 2007

Well it depends where you're coming at it from. If it's Shakespeare then not much, since 'a rose by any other name would smell as sweet', however, if you're ColdFusion 7 running a cfc written for CF6.1, then quite a lot. In fact it's not 'name' so much as 'displayName' that when included in a <cfcomponent> tag causes some horrible errors.

Stuff like 'coldfusion.jsp.CompilationFailedException: Errors reported by Java Compiler: Found 1 Semantic error compiling ... throws javax.xml.rpc.ServiceException;'

what is that all about and what is it with the displayName attribute of the cfcomponent tag that makes CF7 throw a hissy fit when CF6 just carries on regardless. CFEclipse still hints displayname when you open a cfcomponent tag, just don't go there if you're running CF7, and before you ask, I haven't tried it on CF8 yet.