Standalone client to send JMS messages to a JBOSS queue via JNDI

Pretty trivial exercise. But needs a few steps and unless you know exactly what you are doing, it might cause a lot of pain.

Firstly, you’d need the JMS connection factory and queues configured in the local JBoss. This is pretty easy to do.

A client jar is required for the InitialContext located at <JBOSS-HOME>\bin\client\jboss-client.jar

Secondly, you’d need something of the following:

import java.util.Collection;
import java.util.Hashtable;

import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.JMSException;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TextMessage;
import javax.naming.InitialContext;
import javax.naming.NamingException;


public class LocalJBOssMQSender {

     * @param args
    public static void main(String[] args) {

        try {

            Hashtable< String, String > envProps = new Hashtable();
            envProps.put("java.naming.factory.initial", "org.jboss.naming.remote.client.InitialContextFactory");
            envProps.put("java.naming.provider.url", "remote://");
            envProps.put("", "xxxx");
            envProps.put("", "xxxxxx");

            InitialContext ic = new InitialContext( envProps );

            ConnectionFactory cf = (ConnectionFactory)ic.lookup("jms/<connection factory name>");
            Queue inboundQueue= (Queue)ic.lookup("jms/queue/<QueueName>");

            Connection connection = cf.createConnection();

            Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
            MessageProducer producer = session.createProducer(inboundQueue);

            //pick up all .xml files in a given directory and send them as messages to the queue.
             Collection<File> files = FileUtils.listFiles(new File("C:\\temp\\test"), 
                        new WildcardFileFilter("*.xml"), DirectoryFileFilter.DIRECTORY);

                for(File file : files){


                    String messageStr = FileUtils.readFileToString(file);
                    TextMessage message = session.createTextMessage(messageStr);

                    //message.setStringProperty("messageType", "Presentation");
                    // Start the connection

                    System.out.println("Sent message:\\n" + message);


        } catch (NamingException e) {
            // TODO Auto-generated catch block
        } catch (JMSException e) {
            // TODO Auto-generated catch block
        } catch (IOException e) {
            // TODO Auto-generated catch block



Entrust issue on IBM WAS 8.0.5

My most recent challenge:

A perfectly working piece of code running on JBoss 7 that uses encryption using Entrust , fails with the following on IBM WAS 8.0.5 –

Caused by: com.entrust.toolkit.exceptions.PKCS7Exception: internal error at Source)at Caused by: java.lang.RuntimeException: Error from EncodeListener: Unable to calculate encrypted digest: RSA signature failed to initialize for signing: Caught an attempt to access key material in a confined key. at iaik.asn1.DerCoder.encode(Unknown Source) at iaik.asn1.DerCoder.encodeTo(Unknown Source) at iaik.asn1.DerCoder.encodeTo(Unknown Source) at iaik.pkcs.pkcs7.ContentInfoStream.writeTo(Unknown Source)

So, I started out by trying to go through the usual route. Googling didn’t help – nor could I understand what the exception was trying to say.

We built a standalone servlet , deployed on a local WAS trial version and it worked. The local WAS was version 8.5. Deployed the servlet on WAS 8.0.5 – same error.  The only difference was that the cert files were bundled in a JAR file instead of being in the app’s WEB-INF\classes folder.

Changed that in the app, and it began to work !

Or so i thought. The actual issue was finally found to be a completely different. It had to do with how our apps were packaged. In the actual environment we had 2 web apps having the same common utility jar being bundled individually with the web apps. However, this common piece of encryption util was @Autowired – Spring’s way of telling that the component will be ready to use as soon as the apps were deployed. Now, this auto-wiring was happening for the other web app and once loaded by the classloader, this wasn’t available for loading again when it was actually required by the other app. Hence the issue. We changed the bean definition to load laziy in the context file with lazy-load=”true” and that finally solved the issue.

Sidenote: we raised this issue with IBM’s EMR – and the response was that we were using a third party library not supported by IBM ! Take that IBM – you don’t even know what works in your app server and what doesn’t !!