Contributions
Re: WS response elements alphabetized - fails xsd validation
Summary I got from our developers - prior to Java7/J2EE5/WL12 Weblogic generated the soap response in A-Z (ignore case) order by default; J7/J2EE5/WL12 generates in A-Z(case sensitive) order by default. The annotation @XmlAccessorOrder(XmlAccessOrder.ALPHABETICAL) should generate the A-Z(case sensitive) wsdl, but for some reason did not. Our build included a wsgen setting of xendorsed="true" ; changing this setting to 'false' allows the annotation to be honored and the result is a case sensitive wsdl which we use on the client side to validate against the WS response. Apologies I dont have the time or understanding to post a better explanation; hopefully there are enough clues there to help the next person who hits this. -tom11 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes0CommentsRe: WS response elements alphabetized - fails xsd validation
Thanks Paul! Good insight about always having been alphabetic, one we overlooked since our xsd is ordered the same way. But that got me thinking about order and case, and made me realize another difference between what used to work and what doesn't now. The previous setup (working) was running on Unix; for lack of servers, the current version setup (failing) is installed on Windows 7. Possibly significant information that I neglected to include - my bad! Anyway, the OS difference gives us something else to look at. I'll be back when we know more. -tom11 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes0CommentsRe: WS response elements alphabetized - fails xsd validation
Thanks for the reply Paul. Yes , we (both QA & Dev team) agree it is almost certainly not soapUI. That's why I posted in the general forum. Was hoping someone might have insight into why the webservices are building the response according to some lexical ordering instead of following the xsd sequence ... hopefully something along the lines of 'with the new xyz library that comes with the new Weblogic server you have to configure the foo switch ' or something As far as we can tell, our webservices code has not changed, nor has our soapUI version or test projects.11 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.4KViews0likes0CommentsWS response elements alphabetized - fails xsd validation
We're using soapUI Pro 4.6.4, and Oracle Weblogic. Our webservices work as expected on weblogic 10.3; the responses can be validated against the schema. We have recently upgraded to Weblogic 12. We now get responses which contain the proper elements, but the elements have been ordered alphabetically, which gives us schema validation errors. Response running under Weblogic 10.3 - this will validate against the schema. <response> <Aelement>data</Aelement> <belement>data</belement> <celement>data</celement> <Zelement>data</Zelement> </response> Response running under WL 12 - this will not validate because the Zelement is out of proper sequence. <response> <Aelement>data</Aelement> <Zelement>data</Zelement> <belement>data</belement> <celement>data</celement> </response> Any idea what's changed to make this happen? More important, any suggestions what we can do to get the responses to be returned in the the order specified in the xsd files? Thanks. If it's not something silly we're overlooking, we don't understand why we can't find anything ont eh web about this ; I'd expect an uproar...11 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.4KViews0likes5CommentsRe: Form Editor - Error Initializing Editor from Message
Thanks for the reply Arian. Unfortunately, I can't really share the project file, though I know that's a reasonable thing to want to see. Company rules and all I did an edit in the XML editor, and that seems to have brought the form editor back to working properly. I dont know whether it was because I used the XML editor and that caused some sort of refresh, or whether it was the edit itself. The edit was to remove a troublesome character in the name of a test step. The test step name contained an ampersand like: "My Test Step PC1&2" I changed that to "My Test Step PC1and2" There was no indication of any problem in the test step itself; only subsequent test steps that referenced that one. I did eventually realize that several subsequent steps that referenced "My Test Step PC1&2" also had the form editor problem. The ampersand showed up nicely escaped in the XML editor in the references, but I didnt like it (and thought maybe it was causing trouble), so I changed the name. I think it was the ampersand that was confusing things. At this point, I think the issue is resolved unless it pops up again11 years agoPlace ReadyAPI QuestionsReadyAPI Questions2.7KViews0likes0CommentsForm Editor - Error Initializing Editor from Message
I have a number of test steps which run OK, but if I open them, I get a dialog box with the title 'Error Initializing Editor from Message' and asking me "Do you want to recreate a default message from the schema?". If I say yes, my message is replaced with all elements ... not very useful If I say no and look at the test step with the XML view, the message is as I expect it to be. And it runs OK. But I can't use the form view anymore on that message. I don't know how many messages are like this, since it only shows up when I open the test step. Couldnt find any clues in the log files. So I edited soapui-log4j.xml to set all thresholds to debug in the hope of maybe seeing something of interest, but did not. Any idea what is wrong, or what I can do? Thanks -tom11 years agoPlace ReadyAPI QuestionsReadyAPI Questions3.6KViews0likes4CommentsRe: [Resolved] Namespace and changed endpoint
Can't speak for the original poster, but I'm done. -tom12 years agoPlace ReadyAPI QuestionsReadyAPI Questions4.1KViews0likes0CommentsRe: [Resolved] Namespace and changed endpoint
Hmmm ... so I went and tried one more time to use the Refactor Definition, and it ran reasonably quickly. No idea what changed. Still not useful, though - every test step and assertion and property transfer has the original namespace, so while the port binding information is updateable, every test step has to be modified by hand. That obviously wont work. Something else that is interesting - the PortBinding namespace after the Refactor does not show as having been changed unless I close the project and then reload it. Memory consumption just keeps climbing still. Started out at 780Mb, now up to 1.8G after refactoring 5 PortBindings, and saving and reloading the project a few times. Executing GC in the memory log window has no apparent effect.12 years agoPlace ReadyAPI QuestionsReadyAPI Questions4.1KViews0likes0CommentsRe: [Resolved] Namespace and changed endpoint
SoapUI Pro 4.5.1 I've got exactly the same problem - I need to basically clone my workspace and point at a new version of the webservices. If I do an update to the definitions, the namespace does not change, either in the PortBindings nor in the test steps and the assertions and property transfers in the test suites. Although the 'Definition Parts' in the port binding overview pane do change correctly. The url and the version are defined in project level properties, so for example the service endpoint entry looks like: http://${#Project#ServiceEndpoint}/${#Project#IntegrateVersion}/services/CardService If I try the refactor definition, I get a dialog saying 'Missing matching binding [{http://blahblahmyUrl/v2_1}CardServicePortBinding] in definition, select new binding to map to and there is a selection box with the {theNewNamespace}CardServicePortBinding If I select that, soapUI gives me the hourglass, starts consuming hundreds of megabytes of memory ... I let that run for at least 10 minutes and finally decided to kill it. I don't know whether it would ever succeed, but that is ridiculously slow considering I have 18 services in 7 projects that need to be updated. I can't figure out where the namespace is coming from. I can't find it in any wsdl files. Obviously it is in the project files I copied, but it seems like there must be someplace where it was originally generated ... be nice to find that point and fix it there. I don't really want to edit the project file outside soapUI, but its beginning to look like I'll have to12 years agoPlace ReadyAPI QuestionsReadyAPI Questions4.1KViews0likes0CommentsRe: screen refresh / lockup / unable to save project
Been a long time, but thought I'd update the info - now running Windows 7 Pro, on a new computer with and soapUI Pro 4.5.1 . Have not hit the problem since, and am happily able to use my larger second monitor for soapUI. No idea which of the many variables fixed my issue .... but it's all good now12 years agoPlace ReadyAPI QuestionsReadyAPI Questions1.8KViews0likes0Comments