Forum Discussion
Addinonal remark on plugin type - one thing I forgot to mention on this, is that I had heard few months ago that Smartbear were planning to port the SoapUI NG / new style plugin framwork back to open source SoapUI, which would be a nice move if they were to do it. Although I don't know when this might happen - maybe some from SmartBear / dev team has some news here?
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" ?
- rupert_anderson10 years agoValued Contributor
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
- rupert_anderson10 years agoValued Contributor
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,