Forum Discussion
Hi,
Yeah, it got messy for me too when I tried it..
Aside from getting Groovy to override the lib path, maybe just as a experiment, have you tried adding the problem (duplicate) dependencies first (or in front of lib) in the classpath e.g. in soapui.sh something like
SOAPUI_CLASSPATH=$SOAPUI_HOME/bin/soapuilib_http_teststep_patch-1.0-sample.jar:$SOAPUI_HOME/bin/soapui-5.2.1.jar:$SOAPUI_HOME/lib/*
I've done this successfully before in simpler cases - of course in this case it may be counterproductive!
Thanks,
Rupert
Rupert,
It does not seem to work; also it looks like the dependencies fetched via Grape are nto available since it's complaining again the aws classes are not found. All in all it feels not stable to me...
I'm switching to the github open source edition to get latest (and hopefully greatest) ;-) but i'm having doubts if i can overcome the dependency hell...
The best solution would be to have groovy scripts running in a sandbox (alike virtualenv for python if you will), it will make it much more flexible to run whatever version of jars that you need. For instance i'm seeing that if i replace the httpclient 4.1.1 with the newest version (that aws requires) then soapui does not startup anymore ... :-(
Paul
- Paul4248 years agoOccasional Contributor
Hello Rupert,
I was thinking about the external wrapper as well but the downside is then the interface towards that wrapper, in a sense that you will need to think of something support certain arguments etc... and also the results are obviously verbose so you'll need to parse the returned json or whatever you get. It's all overhead in this approach, that is actually the beauty of integrating with the sdk; you'll have 'native' access to the interface of the sdk....
Anyway we are rethinking our approach; soapui does not seem to be a tool for automated component/integration testing which includes reading back/comparing responses and i believe it will be much easier to implement something with plain unittest's in python. You simply import the boto3 (sdk) and it'll work :-)
If i may advise on scripting capabilities for soapui....: support Python ;-) If you support the runtimes from a virtualenv you will not have the issue's like dependency hell i have been in; that has been proven to work very well for years... Also it could give soapui a boost since the Python community is very big.
Paul
- Paul4248 years agoOccasional Contributor
More problems... the github version does not build out-of-the-box; some javafx dependency issue... I have no time to go through that now, i think this is going to be a dead end... :-(
- rupert_anderson8 years agoValued Contributor
Hi Paul,
I think after adding ivy grapes does work at least? I realised my example of commons-lang was a bad one, since SoapUI includes this already in its lib folder. So I tested with something SoapUI doesn't have:
@Grab(group='org.springframework', module='spring-orm', version='3.2.5.RELEASE') import org.springframework.jdbc.core.JdbcTemplate log.info JdbcTemplate.class
This works. If I comment out the @Grab and restart SoapUI, its unable to resolve the class.
Back to the AWS SDK, this was my originally feeling that building from source and working out a fix (involving upgrading some to the core SoapUI dependencies) is the best approach. Could be added as a feature request https://community.smartbear.com/t5/SoapUI-Feature-Requests/idb-p/SoapUIFeatureRequests, I expect others may vote for it, I will, I might even do it if I get some time.
Or as we discussed, making an external wrapper, would also be good.
In reference to building from source, I promise you it does work, I contributed a fix recently. Iv'e done this from both Mac and Ubuntu Soapui source builds. I think I've seen that javafx issue - I can't quite remember whether it was related to the JDK version - are you using open jdk?
Sure, it's been really good of you to be determined to try and work through the issues and share your findings thus far, hopefully it can help one way or another. I just wish I had more time to work on this stuff too! :-)
Thanks,
Rup
- rupert_anderson8 years agoValued Contributor
Hi Paul,
Thanks for your reply.
Yes, creating a wrapper is no easy option as you say.
Sure, I appreciate that a change of approach may be the best plan for you. SoapUI is primarily an API testing tool and the Groovy scripting potentially allows it to do much more if required e.g. support other types of integrations and test related support tasks, but possibly in your case it's not the best choice.
I think your last point is another really interesting one, although obviously not a short term option. I have wondered a couple of times how Python scripting could be worked into the platform, in particular I was looking at Jython for this. Unfortunately, all my SoapUI stuff has to be done in my spare time so I have limited bandwidth to pursue all my ideas, which I am storing up! If you have any other ideas on how best to exploit Python within SoapUI, please share them or add a feature request. It could be a really good feature down the line!
Thanks again,
Rup
Related Content
- 10 years agogus
- 6 months agosohailalam2696
- 3 years agofdelmoro
Recent Discussions
- 10 hours agoemoya
- 14 hours agoMyBalanceNow