Contributions
Re: Issues using 4.1 Soapui on Lion OS
Hi guys, this is still an issue, at present SoapUI is unusable for me which is quite unacceptable. It's blocking my test effort, which means I not only have a licence to an unusable piece of software, but I also and losing valuable time on a critical release schedule. When I try to launch the soapUI-Pro-4.5.0.app with the argument you suggest I get an error. I don't see how you can pass an argument to an app in MacOS. If I use the open "app" route I get an error from the terminal stating that the argument is invalid for the process open, which makes sense. If I try to use the open JavaApplicationStub route I get a similar problem. I can't even find a config to set this argument in so as it gets called automatically when I launch the app via the usual MacOS method. Can you provide the full text for this workaround? What should I be typing to get this to work without error? Regards, Richard12 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.3KViews0likes0CommentsRe: Issues using 4.1 Soapui on Lion OS
Seems that the same issue occurs on the nightly build. 4.02. The screen locks up when the "licence" check dialog pops up. This problem is persistent and occurs each time I start Soapui, effectively making it unusable.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.3KViews0likes0CommentsIssues using 4.1 Soapui on Lion OS
Hey guys, I've moved to using a different dev setup and have had to migrate my machine. I've installed soapui 4.01 but am encountering an issue when the app loads first. I cannot get past the licence screen. The app hangs every time and I get the candy wheel of death. Have you guys encountered this before? In the meantime I'll try installing the nightly build. cheers, - Richard Fortune13 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.7KViews0likes7Comments- 13 years agoPlace ReadyAPI QuestionsReadyAPI Questions8.1KViews0likes0Comments
Re: Just cost me days of work
You can't blame the program for your lack of back up policy. If it's worth keeping you should be storing it in source control - there is no excuse for not doing that. You say you leave your machine on all the time - what would happen if the machine itself failed? (hard disk failures are common) Who would you blame in this scenario? Lesson 101 at Comp-Sci - back it up - or face the consequences. I sympathize with your situation, but if there is a real issue with Soapui not behaving as you expect, then you'll need to give the team a little more to go on other than what you wrote in your post. Start by providing the Soapui build number, the methods you used to save the files (save or save as), the expected behaviour, the pattern of the missing content - was it random or was it sequential?13 years agoPlace ReadyAPI QuestionsReadyAPI Questions556Views0likes0CommentsCannot use XPath in Property Transfers
Hi guys, I've come across this issue where I cannot use the xPath locator in the Property Transfer if I have used groovy/dynamic expansion in the destination request. For instance - in if I want to transfer a GUID into the ReceiptId node in the following request I have to remove the groovy in the Date node before using the xpath helper to locate the Receipt ID node. <Receipts> <Receipt> <ReceiptID></ReceiptID> <User> <UserID>${#randUserID}</UserID> </User> <Contact> <Name>Legitimate Expenses Inc.</Name> </Contact> <Date>${= String.format('%tY-%<tm-%<td', new Date()) }<Date> <Reference>REF-MOJO</Reference> <LineAmountTypes>Inclusive</LineAmountTypes> <LineItems> <LineItem> <Description>Nougat</Description> <UnitAmount>4.15</UnitAmount> <LineAmount>12.45</LineAmount> <AccountCode>400</AccountCode> <Quantity>3.0000</Quantity> </LineItem> </LineItems> <Url></Url> </Receipt> </Receipts> I get the following error when I try to find the node in the Property Transfer dialog screen: Failed to select XPath for target property value [ ${#randUserID} Legitimate Expenses Inc. ${= String.format('%tY-% REF-MOJO Inclusive Nougat 4.15 12.45 400 3.0000 ] Note:Using dynamic expansion/groovy in requests also prevents the Format XML- Alt F functionality from working correctly. UPDATE: I've found a workaround, where I transfer the value into a Property step and then use proper property expansion to supply the ReceiptId (in this case). It's not pretty, but it works.13 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes0Comments