Well, I posted a case and got a workaround: replace commons-beanutils-1.8.3.jar in {ReadyAPI install}/lib with commons-beanutils-1.7.0.jar from {SoapUI Pro install}/lib.
Seems to do the trick :-)
Well, I found something when opening the ready-api-soapui-131.jar file and looking at the JMSConnectionHolder code. It seems there are 2 of those, but one is depricated.
The old one has the following code:
public JMSConnectionHolder(JMSEndpoint jmsEndpoint, Hermes hermes, boolean isTopicDomain, String clientID, String username, String password)
The new one is this:
public JMSConnectionHolder(JMSEndpoint jmsEndpoint, Hermes hermes, boolean isTopicDomain, String clientID)
Part of our groovy-script is the following:
def jmsConnectionHolder = new JMSConnectionHolder( jmsEndpoint, hermes, false, null ,null ,null );
So we were using the old JMSConnectionHolder.
What I did was delete the two 'null' variables we were sending so our code now read the following:
def jmsConnectionHolder = new JMSConnectionHolder( jmsEndpoint, hermes, false, null );
Bingo! The missing dll-file error has dissapeared.
Unfortunately, the next line now gives a nullpointerexception. This is the line that is now giving a problem:
Session queueSession = jmsConnectionHolder.getSession();
For info, here is our part of our groovy-script:
import com.eviware.soapui.impl.wsdl.submit.transports.jms.JMSConnectionHolder
import com.eviware.soapui.impl.wsdl.submit.transports.jms.util.HermesUtils
import com.eviware.soapui.impl.wsdl.submit.transports.jms.JMSEndpoint
import hermes.Hermes
import javax.jms.*
def queue = 'jms://FAT::queue_' + context.expand( '${#Project#Omgeving}' ) + '.UQ.WEKKER_AFGEGAAN.LQ'
//def jmsEndpoint = new JMSEndpoint("jms://FAT::queue_FPT.UQ.WEKKER_AFGEGAAN.LQ");
def jmsEndpoint = new JMSEndpoint(queue);
def hermes = HermesUtils.getHermes( context.testCase.testSuite.project, jmsEndpoint.sessionName );
//def jmsConnectionHolder = new JMSConnectionHolder( jmsEndpoint, hermes, false, null ,null ,null );
def jmsConnectionHolder = new JMSConnectionHolder( jmsEndpoint, hermes, false, null );
Session queueSession = jmsConnectionHolder.getSession();
Queue queueSend = jmsConnectionHolder.getQueue( jmsConnectionHolder.getJmsEndpoint().getSend() );
MessageProducer messageProducer =queueSession.createProducer( queueSend );
TextMessage textMessageSend = queueSession.createTextMessage();
It's set up per the example found here: http://www.soapui.org/jms/working-with-jms-messages.html
This is the error from the log:
2015-06-05 15:41:27,742 ERROR [errorlog] java.lang.NullPointerException
java.lang.NullPointerException
at com.eviware.soapui.impl.wsdl.submit.transports.jms.JMSConnectionHolder.getSession(JMSConnectionHolder.java:152)
at com.eviware.soapui.impl.wsdl.submit.transports.jms.JMSConnectionHolder$getSession.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:110)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:114)
at Script6.run(Script6.groovy:18)
at com.eviware.soapui.support.scripting.groovy.SoapUIGroovyScriptEngine.run(SoapUIGroovyScriptEngine.java:92)
at com.eviware.soapui.support.scripting.groovy.SoapUIProGroovyScriptEngineFactory$SoapUIProGroovyScriptEngine.run(SoapUIProGroovyScriptEngineFactory.java:76)
at com.eviware.soapui.impl.wsdl.teststeps.WsdlGroovyScriptTestStep.run(WsdlGroovyScriptTestStep.java:155)
at com.eviware.soapui.impl.wsdl.panels.teststeps.GroovyScriptStepDesktopPanel$RunAction$1.run(GroovyScriptStepDesktopPanel.java:263)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Unfortunately this only prolonged the problem to another line.
The constructor you were using previously allowed you to create a connection directly to your broken when creating the connectionHolder. The constructor you are using now prolongs the creation of that connection, but since the connection is not yet created there is no session to get. You can verify this by running jmsconnectionHolder.createConnection() right after creating it with your current constructor.
So we're not there yet unfortunately. I'm just about to try some debuggin on this, i'll get back to this thread soon with my findings.
Two kinds of news.
The bad news:
I haven't been able to fix the problem
The good news:
I have downloaded a WebSphere 7.5 trial and reproduced your exact problems and can tinker with it to see if i can find a workaround for it.
I'll be in touch.
Thanks. Looking forward to your findings.
This morning, I extracted the properties ReadyAPI uses to create the connection. As can be seen, the values of XMSC_WMQ_CONNECTION_MODE and XMSC_WMQ_QUEUE_MANAGER are not correctly set.
When doing the same in SoapUI, both properties are correctly set.
I've attached the properties. I've used the following statement to see them;
def connectionFactory = hermes.getConnectionFactory();
log.info connectionFactory;
