There must be someone using one of those three gems under jruby.
Unfortunately, its not currently possible. At least not easily. Those
three gems use MRIs C-Extension API, meaning some of the code in those
gems is written in Native C, instead of in Ruby, and uses the C
API to call functions in the C-code.
JRuby does not currently implement the C Extension API. JRuby has an
api that it uses for interacting with Native C libs, but this is not the
same thing. In the past there was an experimental support for
in jruby but it has been removed because it had poor compatibility., and
was a lot of work to maintain.
Just as MRI (Matzs Ruby implementation) , which is written primarily in
would not be able to integrate with Java libraries without using
to get the two talking to each other, JRuby, written in Java, cannot so
easily integrate with code written in C.
If you are using JRuby, you will need to find a Java way to interact
WMQ. It might be possible to fork one of those gems, write an FFI
around the C-Extension, and get it working that way. Because the
C-Extension API and the FFI API are completely different, you will
need to rewrite both the C code and the Ruby code. That sounds like a
deal of work
You should definitely be able to use the previously mentioned jruby-jms
to interact with it though, as ibm definitely seems to provide a means
interact with jms on their
If It were me, Id write a nice ruby wrapper around the IBM java
and wrap them in a way which would compose cleanly with the jruby-jms
If you do that, you should be able to write application code which is
as clean and simple as what rubywmq provides . To begin with, you
even need to write wrappers for every class, just the ones you needed to
work with for your application. This should certainly be easier than
to write FFI layers for all those C files in the C-Extension gems.
There is also a second, non-JMS java
IBM appears to provide, which seems to be what the above example
script is using. You may also find the following information useful:
MQ Using Java
If you havent much experience interacting with Java from JRuby, I
recommend taking a look at Calling Java from
even better, reading the book Using
I hope this helps and that you now understand why you will probably not
find anyone using those gems from jruby.
The example posted by Charles generates the following:
NameError: missing class or uppercase package name
That indicates that com.ibm.mq.MQQueueManager, referenced in the code is
not on the classpath. You will need a jar containing the java class
MQQueueManager, from ibm, and you will need to either add it to the
classpath at the command line, or by requiring the jar in your code.
help you figure out where those jars are located in your system.
Then you can add them to your classpath either via the command line.
in order to get any of this to work, you also have to pass the library
path which the wmq classes
This library path is different from the classpath, and tells java where
find the native libraries it needs which have been wrapped via JNI by
IBM java classes. You can get both classloader and java.library.path in
go by starting your script like this:
$ jruby -J-cp ‘.:/opt/mqm/java/lib/*:/opt/mqm/java/lib64’
Its also possible to use JRubys require to add jars to the Java
classpath. Unfortunately, there is no decent way to change the
java.library.path property programatically. The JVM essentially sets
property in stone on startup and even if you make changes to it, it wont
pick them up. (Trust me, Ive wasted hours on this in the past). You can
either pass it at the command line, as before, or set an ENV var (
LD_LIBRARY_PATHS) before running the script (yes, Ive tried setting the
ENV from the ruby code. Doesnt work.) So, heres how Id do it:
$ export LD_LIBRARY_PATH="/opt/mqm/java/lib64/"
$ jruby wmq.rb
Then, in your ruby script, require the jars you need like this:
require ‘java’ # Optional on JRuby
MQM_JAVA_PATH = "/opt/mqm/java"MQM_JAVA_JAR =
define the name of the QueueManager
qmgr_name = “QM_edub”# and define the name of the Queue
q_name = “SYSTEM.DEFAULT.LOCAL.QUEUE”
… the rest of the script
If you really need to figure out where those library classes are
dynamically, your best bet is to write a short script that finds them,
the LD_LIBRARY_PATH ENV var, and then launches your real script either
subprocess of some sort, or as a new process. Fairly easy in Bash.
Notice I changed the name of the QueuManager from what was referenced in
the script. This was another gotcha I found. The QueuManager in your
must be named for a running QueuManager instance.
I ran into a couple of other gotchas, just getting wmq installed and
running (Ubuntu 12.04 here). Ill describe below.
well Im on the same boat, I have to make it work soon, just having a
time getting my hands on the IBM jars, there registration site is not
functioning I even called IBM. Ill try again.
Charles, I was able to register with IBM and download the WebSphere MQ
tarball via this link
http://www.ibm.com/developerworks/downloads/ws/wmq/. If you are
still having trouble with registration, the problem may be on
your end. I had to download the entire installation tarball, convert
from .rpm archives to .deb archives and install them with dpkg to get
working on Ubuntu (they seem to only have rpm installers available for
linux) (instructions were found
$ sudo apt-get install alien dpkg-dev debhelper build-essential
$ sudo alien --scripts MQSeriesRuntime-.rpm MQSeriesServer-.rpm
$ sudo alien --scripts MQSeriesSDK-.rpm MQSeriesJava-.rpm
MQSeriesJRE-.rpm MQSeriesExplorer-.rpm MQSeriesMan-.rpm
$ sudo dpkg -i mqseries*.deb
but once I did, the jar files were installed to /opt/mqm/java/lib.
You will need to add your user to the access group mqm. This differs
system to system, of course. On Ubuntu (likely all linuxs), its done
$ sudo usermod -a -G mqm edub
Dont leave out that -a or youll add yourself to mqm but simultaneously
remove yourself from every other group. This process will be totally
different on Windows and maybe OSX. I think, for pretty much every OS
what I read, you will need to log out or reboot and log back in for WMQ
pick up this change. Wasted a bunch of time on that, personally.
I, personally, ran into this
so I will point it out to save you trouble. Only, I never saw anything
work, like some users in the thread. I just couldnt get anything running
at all, just saw that error in the log file (which are stored in
/var/mqm/errors on my machine, generally Ive found everything in either
/opt/mqm/ or /var/mqm/). The fix
got me working.
One tricky point: if the computer being used has a dynamic ip, there are
issues related to the default cluster. If/when the ip changes, the
clusters repository cant be found by other queues in the cluster and
will need to be reconfigured with the new ip information. I found I had
delete the earlier cluster/queumanager and just try again.
So, I set out to try to quickly get the example script Charles shared
working, so I could set the two of you on the right path, and ended up
learning far more about QMG than I ever wanted and bruising my forehead
from banging it so much. The QMG documentation is very thorough, and yet
occasionally leaves out crucial details, QMGs error messages are often *
atrocious*, and quite difficult to google for, and the installation is
ridiculously complicated. QMG causes the user to configure it in
places, the environment, at the command line, in config files, and
programatically, as well as via GUI, and both during installation and at
runtime. In fact, I spent an initial hour or so on this out of goodwill.
want users to have a good experience with jruby and to be helpful. But I
only completed this and got it working out of sheer stubborness and
to quit. Note, my difficulties had little or nothing to do with java or
ruby or jruby, and were almost entirely related to QMG itself. It may be
awesome queuing system. I dont know much about it, really. But I think
getting comfortable enough with it to write code for it would require
careful and thorough reading of the
Figuring out how to use the java api via jruby (whether you decide to
the jms api and use jruby-jms or the other), thats going to be the least
hardest part of the job you have ahead of you.
I hope that this is useful and that I saved you both some knee scrapes.