Missing WSDL error.. Trying to add functionality to an existing WSDL - maven

I'm currently trying to add functionality to a WSDL.. I think I did all the changes necessary but after a Soap request I get an error. Out of curiosity I tried to test the original WSDL and it doesn't work anymore, I get the following fault:
<faultstring> Message part {urn:bar:foo}AddRequest was not recognized. (Does it exist in service WSDL?)</faultstring>
I know the request in question is there, but for some reason is not being recognized.
I reverted all changes in all files (hoping it was just a simple mismatch on the WSDL signature) but I didn't have much luck. any ideas?
I'm really new to all these technologies, any help is welcome.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<mule-project xmlns="http://www.mulesoft.com/tooling/project" runtimeId="org.mule.servers.3.2.0.CE">
<name>cdms</name>
<description></description>
</mule-project>

I found the mistake, it was a very obvious thing too :#
I was using the wrong endpoint in soapUI call, so of course I was getting a response but by using the wrong endpoint Mule didn't recognized the WSDL and thus returned a fault

Related

What is the GlobalIdentity and how do I set it in the FileNet web service?

I'm trying to upload a document into filenet via CEWS, but I'm getting this error:
“The unexpected exception is chained to this exception. Message was: com.filenet.apiimpl.core.GlobalIdentity incompatible with com.filenet.apiimpl.core.RepositoryIdentity“
Our Filenet people don't seem to know what that means. They've provided working code that basically looks the same as mine (but which I can't compile directly at the moment because it references parts of their project I don't have.)
So is the GlobalIdentity something I need to pass in through the web service? If so, how? If not, where is it configured?
Ok I finally spotted my mistake.
I had incorrectly set crt.TargetSpecification.classId to the name of the repository I was trying to use rather than to the correct classId.

Upgrade from spring 3.0.4 to 3.2.2 causes 405 get not supported for stylesheet

If I build my application with spring 3.0.4, the stylesheet is downloaded no problem.
If I build it with 3.2.2.release, however, I get a 405 error saying GET is not supported when it tries to get the stylesheet.
No other changes have been made.
I am deploying to Glassfish
Does anyone have any ideas what could cause this?
Does anyone have any ideas what could cause this?
Potentially many things. (My guess would be that some request is being redirected to the wrong place by SpringSecurity.)
But rather than guessing, you would be better off gathering some concrete evidence of what is happening:
In the web browser, figure out exactly what the pattern of requests and responses is. For instance, if there is a redirect happening, find out what it is redirecting too.
On the server side, enable debug logging for your application, the Spring stack, and if necessary Glassfish. This should provide you with more clues as to what is happening.

Wicket.Ajax.Call.failure: Error while parsing response: Object required

I just spent several hours of my life debugging this problem. I'm documenting it here for others.
Question:
I'm getting the following error when I try to click on an AjaxLink in Internet Explorer:
Wicket: ERROR: Wicket.Ajax.Call.failure: Error while parsing response: Object required
It works fine in all other browsers; just IE is busted.
Check to make sure that your HTML is 100% syntactically correct. Ajax responses are returned to the browser inside a CDATA section, and if the payload is not well-formed, IE will sometimes choke.
In my case I neglected to close a <link> tag in the <head> section. Simply closing that link tag made all the difference.
Aside: if you ever come across a tough-to-solve problem in Wicket, it's a good idea to create a quickstart project that reproduces your issue. It can be a lot of work to boil things down, but in doing so you often find the source of the problem.
I want to note one more potential reason for the issue with Wicket's AJAX in IE. It might help someone, who encounters similar problem.
In my case I had the following error message in IE:
Wicket: ERROR: Wicket.Ajax.Call.failure: Error while parsing response: could not find root <ajax-response> element
The reason was an incorrect Content-Type of AJAX response. I used AbstractTransformerBehavior and there was a bug in Wicket 1.4.x so this behavior was rewriting response Content-Type with text/html. IE does not parse such response as XML.

Turn IIS7 HTTP Error Handling Off?

I just got setup on my first Windows Server 2008 / IIS7.5 server for a contest I am participating in. I can't for the life of me figure out how to turn OFF error handling COMPLETELY. The only options I see are:
Custom
Detailed
Detailed Local, custom for remote
I want to turn the feature off completely, and I don't see any way to do that. Am I missing something?
My Situation:
I have a RESTful PHP framework that catches exceptions and emits an HTTP 500 status if the exception has not already been handled. It then puts the specified exception message in the response body and sends it to the browser. This works fine in Apache - the correct headers are sent and the message is displayed to the user. In IIS, however, the response for 4xx and 5xx HTTP status codes is always intercepted and injected with some other prepared message or HTML file, and that's exactly what I don't want it to do anymore. Please help!
After some more extensive searching, I found the answer here:
http://blogs.msdn.com/webdevelopertips/archive/2009/08/24/tip-93-did-you-know-php-and-custom-error-pages-configuration.aspx
The solution is to manually edit your web.config file with this custom "httpErrors" entry:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
However, due to IIS 7.0 "lockdown" feature you might get a "This configuration section cannot be used at this path. This happens when the section is locked at a parent level." error. To solve that, execute the following in the command prompt:
cd C:\Windows\System32\inetsrv
appcmd unlock config /section:httpErrors
In IIS Manager -> Site -> Error Pages, right-click each error page and choose ‘Remove’.
Unfortunately there is not a way to tell IIS not to interfere from the script side, so it's always an annoying deployment issue.

"required field 'EntityId' is missing" error

No matter what i attempt i keep getting the following exception being thrown by MSCRM 4.0
Invalid format of input XML for request SetStateITG_glcode: required field 'EntityId' is missing
here is the captured SoapEnvelope from WireShark going to MSCRM where you can see that there is in fact a EntityId element.
<s:Body><ns0:Execute xmlns:ns0="http://schemas.microsoft.com/crm/2007/WebServices" xmlns:ns3="http://microsoft.com/wsdl/types/" xmlns:ns4="http://schemas.microsoft.com/crm/2006/WebServices" xmlns:ns6="http://schemas.microsoft.com/crm/2006/Scheduling" xmlns:ns2="http://schemas.microsoft.com/crm/2006/CoreTypes" xmlns:ns5="http://schemas.microsoft.com/crm/2006/Query" xmlns:ns1="http://schemas.microsoft.com/crm/2007/CoreTypes" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><ns0:Request xsi:type="ns0:SetStateITG_glcodeRequest"><ns0:OptionalParameters/><ns0:EntityId>f0754ebf-50d2-de11-93aa-000c29af16b6</ns0:EntityId><ns0:ITG_glcodeState>Active</ns0:ITG_glcodeState><ns0:ITG_glcodeStatus>1</ns0:ITG_glcodeStatus></ns0:Request></ns0:Execute></s:Body></s:Envelope>
here is SOAP body submitted to MSCRM captured again by Wireshark; this message came from a quick console application i wrote to do the update i am trying through my web service client above.
<s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><Execute xmlns="http://schemas.microsoft.com/crm/2007/WebServices"><Request xsi:type="SetStateITG_glcodeRequest"><OptionalParameters/><EntityId>c2fcef74-19cf-de11-9376-000c29af16b6</EntityId><ITG_glcodeState>Inactive</ITG_glcodeState><ITG_glcodeStatus>-1</ITG_glcodeStatus></Request></Execute></s:Body>
the second message work; and MSCRM does what it is meant to do.
the first one, which other than the namespace prefixes, is the same structure ... as far as i can see.
am i missing something obvious?
what is MSCRM moaning about?
Thanks
so this problem is fixed...
turns out MSCRM didn't like the namespace prefix of ns0
is MSCRM using a custom string parsing based Xml vlaidator or something ridiculous?

Resources