A trick to help with the Eclipse update blues

I think anyone who uses Eclipse has cussed at the software installer/updater/marketplace.  Tonight I tried to install the eGit plugin from the marketplace with no luck.  As usual, every time it tried to download something from download.eclipse.org, usually content.jar, it would hang until the 600s network timeout elapsed.

I did a little googling and stumbled upon a JVM setting that fixed the problem in this instance.  Crack open the eclipse.ini and throw this parameter into the -vmargs:

-Djava.net.preferIPv4Stack=true

After doing that the updates worked great.  All the network communication went by quickly on my cable modem and I wasn't sitting there wondering what the hell Eclipse is doing.  I can live with slow downloads when I can see progress going by but the 10 minute hangs with no feedback...

For what it's worth, the other trick I saw that people found helpful was to go to the 'Install New Software' screen and uncheck the 'Contact all update sites during install to find required software' check box.  That didn't help my issue, the JVM parameter is what did the trick there, but it's worth keeping in mind if updates are mis-behaving.

Any who, maybe this will help someone else out with Eclipse downloads.

Using OpenMQ in Websphere (cliffnotes)

I couldn't find anything on using an OpenMQ message broker with the Websphere Application Server so here are the steps I followed.

Get the software
Download the developer edition of WebSphere
http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/

* NOTE: on Ubuntu, replace the /bin/sh symlink that points to /bin/dash with a symlink that points to /bin/bash.  Otherwise the install will hang half-way through

Download the JavaEE SDK (probably called Glassfish) from Oracle

Setup OpenMQ
Start the imqbrokerd (the actual OpenMQ server)

Start the imqadmin tool, set up a queue, JNDI connection factory and destination.  This tutorial helps explain what to do:
http://docs.oracle.com/cd/E19909-01/817-3727/tutorial.html

Use this sample code to create a tester to make sure you have your queues all set up correctly:
http://www.java2s.com/Code/Java/J2EE/ThisexampleisasimpleJMSclientapplication.htm

Set up WAS
1. Create a new Generic JMS provider
Add these jars to the Classpath for the provider:

${glassfish3}/mq/lib/fscontext.jar
${glassfish3}/mq/lib/imq.jar
${glassfish3}/mq/lib/jms.jar
${glassfish3}/glassfish/modules/glassfish-naming.jar

Where ${glassfish3} is a variable that points to the glassfish3 directory on your system

If you forget one of these jars, werid werid werid exceptions occur that are hard to trouble shoot (catch them and print them to stdout when debugging)

External initial context factory:
com.sun.jndi.fscontext.RefFSContextFactory

External provider URL:
file:///tmp/OpenMQ

This should match the path used for the java.naming.provider.url in the OpenMQ object store

2. Create a Queue Connection factory

Name: lable is free form

JNDI name:
the JNDI name used by apps running in WAS, so this is the name WAS exposes for the resource

External JNDI name:
The JNDI name used in the OpenMQ object store for the ConnectionFactory resource which is listed under the "Lookup Name" column in the imqadmin tool

3. Create a Queue
Same instructions as the connection factory basically, only this time use the Destination in the OpenMQ object store instead of ConnectionFactory

And thats it!  If you're getting weird class cast execption or cannot connect exceptions, double check that all 4 jars are included AND that he external JNDI names matching.

WAS is terrible with it's Generic JMS exceptions. One trick is to catch and System.out.println the exception thrown when trying to pull the resource from JNDI or connect to the broker.  I found that this revealed more helpful exceptions that are not logged by WAS when the error occurs.