How to integrate SoapUI with JMSToolBox
Hi, I'm the author of JMSToolBox (https://sourceforge.net/projects/jmstoolbox), which has similar functionnalities as HemesJMS JMSToolBox as been developepd as an alternative to HermesJMS as it see...
Forum Discussion
I've checked the source code of SoapUI concerning the Soap over JMS feature, it seems that HermesJMS is deeply integrated with SoapUI as you can see in this class : https://github.com/SmartBear/soapui/blob/next/soapui/src/main/java/com/eviware/soapui/impl/wsdl/submit/RequestTransportRegistry.java
I dont know how to override the "RequestTransportRegistry" as everything is hard coded and I don't think a "regular" plugin can be use to associate the JMS transport to JMSToolBox in anyway
Maybe there is a way to add an entry to this "RequestTransportRegistry" ?
Hi,
I have only had a quick look, but what you are saying regarding the limitations of the current SoapUI code and plugin architecture might mean that your best route is joining the SoapUI OS project on GitHub and maybe adding JMSToolBox as an enhancement to the core product? Have you contacted SmartBear Staff about anything like this?
It seems like a good opportunity for you to help them improve their product and I got the impression from the Hermes JMS project (and some issues gettting it to work with more recent versions of ActiveMQ) that it went dormant.
Thanks,
Rupert
Hi,
I'm not ready to go this way, and to be honest, I.'m not sure to integrate JTB code directly into SoapUI as it is done for HermesJMS is a good idea..IMHO this kind of coupling is a very bad idea, las is the installation of HermesJMS with SoapUI..
A plugin seems to be the right answer but I don't know where to start from, adding a new "transport" for the request seems the way to go but I don't know if it is possible via a plugin
Hi,
You are of course right about not introducing another tight coupling to another JMS tool kit, but I think the Hermes stuff was done long before the plugin framework was developed. I understand that you would rather not go this way, but I am also uncertain whether the plugin framework can accomodate your software without changes and not able to make this judgment off-the-cuff on the strength my pluging experience.
Have you tried contacting any of the SmartBear guys about this? Some of the people in this post may be good options:
In particular, MattiH and MFagerlind and possibly nmrao - sorry to drop names, but this seems like quite a hardcore plugin topic / product enhancement opportunity.
Hopefully they can offer some advice or explain where to go next.
Thanks,
MFagerlindStaff
Sorry for the late reply guys - it wasn't because I didn't think this was interesting. It definitely is! I've been on an extended holiday and just came back.
As one of the authors of the plugin framework in Ready! API (Ole Lensmar being the other), I have a strong feeling that this should be possible. However since I didn't build the JMS support and haven't worked much with it, I'm far from sure that this feeling should be trusted. Here there be dragons!
The general idea is quite simple though. You need to build a plugin with a RequestTransport implementation and bind it to the prefix "jms". The class definition should look something like this:
@PluginRequestTransport(protocol = "jms")
public class JmsToolBoxRequestTransport implements RequestTransport {This new transport class should completely replace the Hermes based class (com.eviware.soapui.impl.wsdl.submit.transports.jms.HermesJmsRequestTransport). In theory this should, and could, Just Work (tm). In practice there may be some hardcoded dependencies on Hermes that will trip you up. We would of course do all we can (within reason) to solve any problems caused by such dependencies, including changing the SoapUI/Ready! API core to make your plugin work.
I'll pass the question on to the other guys and gals in the Ready! API development team in Stockholm (some of whom know much more about the JMS support than I do), and to Ole Lensmar, the creator of SoapUI. Stay tuned!
Kind regards,
Manne Fagerlind, Ready! API developer