We are using Dropwizard 1.0.6 for our Java service. It seems that Dropwizard has eaten some (maybe all) Bad Request (400) error logs as we cannot see it from the service log.
What do we need to do to make sure we log ALL errors including errors reported by Dropwizard components?
Thanks.
Related
Ever since I upgraded from Jenkins 2.2x to 2.36 my Login with IDP isn't working despite the configuration in settings remaining unchanged. I am using Ping for SSO and Ping does indeed authenticate, but after authentication Jenkins throws an error: "An error occurred while reading response." Picture of error is attached.
I talked to my company's SSO guy and after extensive work he couldn't find the problem. Also did extensive research and couldn't find much regarding this problem.
*SAML plugin came out with update that solved the issue
When user is accessing data that is not available in jenkins then user is getting 404 but it's also displying Jetty version, how I can remove this jetty version information from response data?
HTTP ERROR 404
Problem accessing /jenkins/user. Reason:
Not Found
Powered by Jetty:// 9.4.z-SNAPSHOT
Jenkins uses a "Winstone", which is (nowadays) just a wrapper around the Jetty servlet container. So your questions boils down to configuring the 404 message for Jetty. See this question for information on how to do that.
However, it could be more easy to just switch to a different servlet container (like Tomcat) instead.
I have an error importing a WSDL definition from an ASP.NET version 4 Visual Studio 2010 Express project, into SOAPUI 4.5.1
URL would be like
http://localhost:7929/ws/AX.asmx?WSDL
Error generated
Error loading [http://localhost:7929/ws/AX.asmx?WSDL]: org.apache.xmlbeans.XmlException:
org.apache.xmlbeans.XmlException: error: Unexpected element: TAG_END
Error trace:
com.eviware.soapui.impl.support.definition.support.InvalidDefinitionException
at com.eviware.soapui.impl.wsdl.support.wsdl.WsdlLoader.loadXmlObject(WsdlLoader.java:138)
at com.eviware.soapui.impl.wsdl.support.xsd.SchemaUtils.getDefinitionParts(SchemaUtils.java:535)
...
Any suggestions most welcome!
I had the same issue with Soap UI 5.2.0
The solution for me was to turn off the proxy (as suggested by #user518066)
The issue is that soapui doesn't know where to find the schema file.
If your wsdl is deployed to a server, it will return a url of the xsd file to include and soapui will be able to find it....
I had the same problem, after several hours I found that the problem was about IPv6.
When I go to service URL I can see and validate the wsdl file. There was no problem at all.
http://localhost/SoapServer.php?wsdl
But when I add this URL to SoapUI it gives error Unexpected element: TAG_END.
I found the reason by using cURL, curl http://localhost/SoapServer.php?wsdl returns 404!!
So realized that my Apache listens both IPv4 and IPv6, browser goes to IPv6 and gets the wsdl but cURL and SoapUI goes to IPv4 and get 404 error.
I disabled IPv6 on my Apache by removing the line Listen [::0]:80 in httpd.conf file, this solved the problem.
Are you sure that the service is running?
When debugging solutions with several WCF projects, there are times in which we could think that we are running the project we are working into and it turns not be that case.
If you face an Error 404 when enter the svc url into a browser, then this could be the cause of the problem.
In that scenario, SOAP UI will fail when trying to add or create a new WSDL endpoint.
So, make sure that your solution starts running from the project where the target svc is located.
I'm trying to deploy my Grails application to AppFog using CloudFoundry plugin (ver. 1.1) in Spring Source Suites (STS 2.9.2).
I'm using https://api.appfog.com as server address and MYAPPNAME.aws.af.cm for application address when deploying app.
Application is pushed and started, services are bounded but, after that, I recive error saying that:
Communication with server failed: I/O error: Server returned HTTP response code: 405 for URL: https://api.appfog.com/apps/MYAPPNAME/application
Also, when I try to create Caldecott tunnel toward database I recive response "The URIs: caldecott-85393a.appfog.com have already been taken or reserved. (404 Not Found)" which I also saw when (by mistake) treid to deploy application to MYAPPNAME.api.appfog.com (default AF name instead of particular infrastructure adress).
I suppose that CloudFoundry plugin uses default server address to reach application and also trying to create Caldecott tunnel on default server address (caldecott-85393a.appfog.com instead of caldecott-85393a.aws.af.cm)
Does anybody have idea how to circumvent this situation?
BR
Zoran
this doesn't sound like an issue with the plugin itself but the response coming back from AppFog's cloud. I would take this up as an issue with them and clarify you can use that plugin with their cloud.
AppFog had issues recently with their Java deployments that was specifically affecting Grails apps. This has been resolved and should be working seamlessly as expected now. You can always reach out for more information in the active google group as well: https://groups.google.com/forum/#!forum/appfog-users
This works locally. Set up: Grails 2.0.3. Debain Linux. I've deployed other applications successfully to Cloud Foundry.
Apparently this thing can happen as a consequence of the Spring Security Plugin not being happy with the resources plugin. Removing the resources plugin doesn't cure this.
This is the problem:
Class: java.lang.IllegalStateException
Message: No thread-bound request found: Are you referring to request attributes outside of
an actual web request, or processing a request outside of the originally receiving thread?
If you are actually operating within a web request and still receive this message, your
code is probably running outside of DispatcherServlet/DispatcherPortlet: In this case, use
RequestContextListener or RequestContextFilter to expose the current request.
Adding the org.springframework.web.context.request.RequestContextListener and its loader to web.xml and importing them into the page doesn't help either.
There is much about this on the web, but in my case it only happens on Cloud Foundry.
Cloud Foundry runs on Java 1.6, like my machine. The logs say the same as the quote above, with stack traces identical to what I've found on the web.
Any ideas? I'm stuck. I've spent the best of two days on this.
Thanks.
Adding compile ":webxml:1.4.1" to the plugins section of BuildConfig.groovy should fix that. Credit to http://support.cloudfoundry.com/entries/21371626-grails-mongodb-deployment-fails