Guy Mahieu’s Blog

At my current job everyone is using eclipse and ivy is the standard dependency manager. I’ve used eclipse as well for the last months, but it could never make me forget IntelliJ IDEA. Too bad IntelliJ still lacks ivy support though…

There are a few plugins around that add (some) ivy support to IntelliJ IDEA but I wasn’t able to get them to work properly; they seem to be written for a specific situation or are a pain to configure.

All of this got me to the point where I started working on my own plugin: IvyIDEA. At first I started out with a quick and dirty way of adding dependencies from a certain folder into a module library in IntelliJ. After a few days and nights of development, I now have it integrated with the ivy resolve functionality. It detects source and document types and adds them as such. As a bonus (and because I was curious how it worked) I also added an IvyIDEA facet in intellij, meaning that ivy.xml files are autodetected and configured to be recognized by the plugin.

It is still very rough around the edges (the exception handling is non-existing and there currently is no output console to see what’s going on during the resolve process) but I use it daily in my job and I hope to have a good enough version ready soon to add to the IntelliJ plugin repository.

If you can’t wait until then, you can always download the source code and compile it on your own from www.ivyidea.org. If you have feature requests, bug reports or comments, please let me know!

Update 2008-10-19: I just saw that JetBrains is organizing an IntelliJ plugin contest, and I decided to submit IvyIDEA as an entry. They suggested to publish a version as early as possible so I decided to already publish a first alpha version to the plugin repository. This means that you can now install the first rough-around-the-edges alpha version using the plugin manager in IntelliJ if you like.

The JMS spec does not provide a way to easily obtain the number of messages on a certain queue. You could create a browser and browse through the entire queue and keep count, but this is very slow.

The java client for MQSeries (or WebsphereMQ as it is called nowadays) does provide this functionality, so if you don’t mind using IBM specific classes, you could do it like this:

public int getDepth(String queueName) throws MQException {
  // Build quemanager (this should be done in another method)
  // and not every time in a real life application
  MQEnvironment.channel = "CHANNELNAME";
  MQEnvironment.port = 1414;
  MQEnvironment.hostname = "qmgrhost.yourdomain.com";
  MQEnvironment.properties.put(MQC.TRANSPORT_PROPERTY, 
    MQC.TRANSPORT_MQSERIES);
  MQQueueManager qmgr = new MQQueueManager("YourQueueManagerName");
  // access the queue to query its depth
  com.ibm.mq.MQQueue queue = qmgr.accessQueue(queueName, 
    MQC.MQOO_INQUIRE | MQC.MQOO_INPUT_AS_Q_DEF, 
    null, null, null);
  return queue.getCurrentDepth();
}

The com.ibm.mq.MQQueue class exposes some other interesting methods to get more information about a queue, like the maximum depth and the maximum message length.

The spring framework provides an easy way for intercepting calls to methods of managed beans. In the project I am currently working at, we wanted to log access to all methods of the Connections returned by a specific datasource. This datasource is defined as a spring bean, but the connections it provides obviously aren’t.

In order to get this done, I decided intercept all calls to the getConnection() method of that specific DataSource an in stead of returning the Connection, I return a dynamic proxy to that connection which will log some method information prior to invoking that method.

Here is the source code and xml config I used to do this…
Continue Reading »