sorry if my english is bad.
I have a problem while calling one of my GWT services.
On the client side, I have the following error.
[ERROR] com.google.gwt.user.client.rpc.StatusCodeException: 500 The call failed on the server; see server log for details
[ERROR] at com.google.gwt.user.client.rpc.impl.RequestCallbackAdapter.onResponseReceived(RequestCallbackAdapter.java:209)
[ERROR] at com.google.gwt.http.client.Request.fireOnResponseReceived(Request.java:287)
[ERROR] at com.google.gwt.http.client.RequestBuilder$1.onReadyStateChange(RequestBuilder.java:395)
...
Unhappily, I can't find any information related to this error on the server logs.
I'm in devlopment mode, and the only thing I can see in jetty is
[ERROR] 500 - POST /my/maping (127.0.0.1) 57 bytes
However, I know that my service implementation is called and that it returns a result without throwing any exception (because I use logs just before the return...) .
I have seen that this problem could be a serialization issue, but I really don't see where I miss something to make my objects serializables, ( plus, gwt compilator generally says me when something is not serializable).
And my/mapping should be finely defined, because it was working previously, and I am pretty sure that I have not modified anything related to this...
Finally, I don't find any interesting answer to my problem.
If you have any ideas, thanks in advance for your help.
ps: I use gwt 2.5.0-rc2.
This problem is mostly related to a class that forgot to implement the isSerializable or Serializable interface. Also Check if all subclassess in that class also implement isSerializable or Serializable interface.
Then verify that all class have a default no argument constructor.
If you are using JPA and the class relations are setup incorrectly, a general 500 will be thrown without an specific error messages
Related
I've got a Domain Driven Design solution and for some reason, I'm getting this exception at RunTime when the API call is made through GateWay:
One or more errors occurred. (Method not found: 'Void FluentValidation.AbstractValidator`1.When(System.Func`2<!0,Boolean>, System.Action)'.)
The error occurs as below:
I have solution like this:
The main 4 project I'm focusing on right now are:
Core.Model
Account.Api
Service.Api.Gateway
Web.ClientSite
Web.ClientSite makes request to Service.Api.Gateway which then calls Account.Api.
Note that Core.Model is referenced everywhere
VERY IMPORTANT: If I remove the reference of FluentValidation from Core.Model, the exception disappears.
I'm hoping these information is enough. Why do you think I'm getting this exception and how can I eliminate.
Looks like some of libs (ocelot) are incompatible with new changes in FluentValidation 8.1.2. Try to downgrade to FluentValidation before 8.1.2. Hope it helps
I got similar exception:
System.MissingMethodException : Method not found:
'FluentValidation.AssemblyScanner
FluentValidation.AssemblyScanner.FindValidatorsInAssembly(System.Reflection.Assembly)'
In my case I needed to upgrade the ediatR.Extensions.Microsoft.DependencyInjection and MediatR.Extensions.FluentValidation.AspNetCore packages as well to fix the issue.
Today I was designing the error handling statergy for a new website. I have gone through all the docs for ColdFusion Excepiton
handling.
Now I have some doubts.
What the best solution for handling 404 errors?
Using onMissingTemplate() method
Sitewide Missing Template option(CFAdmin)
IIS custom 404 error handler.
What is the best solution for exception handling?
What should I use for error logging onError() method or Site-Wide Error handler? Is there any significant difference between
these two?
Do I need to use try/catch block for each and every query that I write?
Because there are some queries where I am sure the query will only fail when the database will fail. So if the database fails ,there is no meaning process the page further using try/catch. What should I do in these situations?
I know this question looks bit subjective , but I can not find a better place than StackOverflow for this.
For handling 404's, its better to handle it at webserver level.
For Sitewide Missing Template, you can specify the same in CF Admin. Ensure that the Sitewide error handler file location, should be relative to CF webroot and not webserver root. The dependent files may be put at the webserver.
Please refer to http://blogs.coldfusion.com/post.cfm/onmissingtemplate, for IIS custom 404 error handler. This recent blog post has a detailed description of 404 and error handling.
The answer is that you should use all three.
onMissingTemplate() is application-specific (remember that you can have multiple applications on a single CF instance).
Missing Template Handler is CF-instance specific.
IIS custom 404 error handler works for non-CF files (e.g., .htm, .html, etc.). You can still, of course, specify a CF template as the custom error handler.
FYI, the application-specific onMissingTemplate() method takes precedence over the CF Admin Missing Template Handler. The latter fires if there isn't an application-specific onMissingTemplate().
As far as exception handling is concerned, that is going to depend on a number of factors, but again a multi-layered approach is good.
I have a problem in catching the exceptions in my spring integration application.
Flow of operations in my application.
Http:inbound gateway which receives the request (error-channel defined to my custom error channel)
Service Activator for basic validations (Exceptions which are thrown from here are handled by error-channel defined on the GW)
splitter
Aggregator
Exceptions on my splitter or Aggregator are not handled by my error channel. why?
Steps taken:
I added a chain and included a header enricher and specified an error channel just before the splitter.
After this, any exception on my splitter is handled by my error channel mentioned in the header enricher.
<chain input-channel="invitations">
<header-enricher>
<error-channel ref="failed-invitations" />
</header-enricher>
<int:splitter ref="payloadSplitter" />
</chain>
But the same doesnt work when do the same on my Aggregator. why?
Whenever there is an exception in my code, it retries and gets executed more than one time. why?
I have a "errorChannel" defined which logs the exceptions. it doesnt work.
I know the thread is too old, but I was also facing a similar issue and found I declared error-channel in header-enricher but not provide 'overwrite="true"' as a parameter. And after providing 'overwrite="true"'it is working as needed. I am surprised why spring integration does not provide an overwrite=true by default.
Let us know this is what solution you did in your old code? So everyone can find out the solution for such a scenario.
I’m struggling fully understanding when/how exceptions are thrown in JSF 2.0. I’ve looked for a solution longer than I care to admit. Ultimately, the goal I want to achieve is “handle” an unhandled exceptions. When an exception is thrown, I want to be able to capture information of interest about the exception, and email that to the appropriate site administrators. I’m forcing an error by throwing a new FacesException() in the constructor of one of my backing beans. I had this working great in JSF 1.1 using MyFaces implementation. I was able to get this working by wrapping the Default Lifecycle and simply overriding the execute() and render() methods. I followed this awesome post by Hanspeter to get that working:
"http://insights2jsf.wordpress.com/2009/07/20/using-a-custom-lifecycle-implementation-to-handle-exceptions-in-jsf-1-2/#comment-103"
I am now undergoing a site upgrade to JSF 2.0 using Mojarra’s. And things work great still as long as the exception is thrown/caught in the execute() method, however; the moment I enter the render(), the HttpServletResponse.isCommitted() equals true, and the phase is PhaseId RENDER_RESPONSE which of course means I can’t perform a redirect or forward. I don’t understand what has changed between JSF 1.1 and 2.0 in regards to when/how the response is committed. As I indicated, I had this working perfectly in the 1.1 framework.
After much searching I found that JSF 2.0 provides a great option for exception handling via a Custom ExceptionHandler. I followed Ed Burns’ blog, Dealing Gracefully with ViewExpiredException in JSF2:
"http://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2"
As Ed indicates there is always the web.xml way by defining the tag and what type of exception/server error code and to what page one wants sent to for the error. This approach works great as long as I’m catching 404 errors. One interesting thing to note about that however, is if I force a 404 error by typing a non-exsitant URL like /myApp/9er the error handler works great, but as soon as I add “.xhtml” extension (i.e. /myApp/9er.xhtml) then the web.xml definition doesn’t handle it.
One thing I noticed Ed was doing that I hadn’t tried was instead of trying to do a HttpServletRespone.sendRedirect(), he is utilizing the Navigationhandler.handleNavigation() to forward the user to the custom error page. Unfortunately, this method didn’t do anything different than what Faclets does with the error by default. Along with that of course, I was unable to do HttpServletResponse.sendRedirect() due to the same problems as mentioned above; response.isCommitted() equals true.
I know this post is getting long so I will make a quick note about trying to use a PhaseListener for the same purposes. I used the following posts as a guide with this route still being unsuccessful:
"http://ovaraksin.blogspot.com/2010/10/global-handling-of-all-unchecked.html" "http://ovaraksin.blogspot.com/2010/10/jsf-ajax-redirect-after-session-timeout.html"
All and all I have the same issues as already mentioned. When this exception is thrown, the response is already in the committed phase, and I’m unable to redirect/forward the user to a standard error page.
I apologize for such a long post, I’m just trying to give as much information as possible to help eliminate ambiguity. Anyone have any ideas/thoughts to a work around, and I’m curious what might be different between JSF 1.1 and 2.0 that would cause the response to be committed as soon as I enter the render() phase of the Lifecycle.
Thanks a ton for any help with this!!!
So this question is actually not just about a custom exception handler (for which JSF 2 has the powerful ExceptionHandlerFactory mechanism), but more about showing the user a custom error page when the response has already been committed.
One universal way to always be able to redirect the user even if the last bit has already been written to the response is using a HttpServletResponse wrapper that buffers headers and content being written to it.
This does have the adverse effect that the user doesn't see the page being build up gradually.
Maybe you can use this technique to only capture the very early response commit that JSF 2.0 seems to do. As soon as render response starts, you emit the headers you buffered till so far and write out the response content directly.
This way you might still be able to redirect the user to a custom error page if the exception occurs before render response.
I have successfully implemented a filter using response wrapper as described above which avoids the response being commited and allows redirection to a custom page even on an exception in the middle of rendering the page.
The response wrapper sets up its own internal PrintWriter on a StringWriter, which is returned by the getWriter method so that the faces output is buffered. In the happy path, the filter subsequently writes the internal StringWriter contents to the actual response. On an exception, the filter redirects to an error jsp which writes to the (as yet uncommitted) response.
For me, the key to avoiding the response getting committed was to intercept the flushBuffer() method (from ServletResponse, not HttpServletResponse), and avoid calling super.flushBuffer(). I suspect that depending on circumstances and as noted above, it might also be necessary to also override some of the other methods, eg the ones that set headers.
I am trying to figure out a clean way to intercept uncaught exceptions that occur in my application.
I have log4j configured for logging the normal application flow and caught exceptions, so that is taken care of. Right now, I have a class that takes all error-level messages and adds them to a queue to be emailed in batches.
Ideally, I'm hoping that there is a way I can go about intercepting the uncaught exceptions, so that I may pass them to the same 'email batch' queue, but if this is not posible, I'm certainly open to suggestion.
I'm familiar with LogInterceptors on JBoss, but this project is using Tomcat. Is there any way that I might go about this? Is there a LogInterceptor equivelant for Tomcat? Should I try to redirect the Tomcat logging to a custom appender? (If so - any hints on that?) Some other ideas?
I figured that this has to be a solved problem by now, so I am hoping to tap some collective wisdom. Thanks, everyone, in advance.
Per the J2EE 1.4 spec, uncaught exceptions within a servlet may be forwarded to an error page as defined in the deployment descriptor. When this happens, the page implementation will receive the original request and response objects, with the addition of a request attribute named javax.servlet.error.exception that contains the exception object.
That said, I have not actually done this with Tomcat, and most of the web applications that I've worked on forward to a generic error page at the webserver level.
Edit: just tried it out on my local server, after adding the following to my web.xml, and it works as advertised:
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/dumpRequest.jsp</location>
</error-page>
It's not Tomcat-specific, but you can set uncaught exception handlers on a per-thread basis.
Depending on the setup of your application, you could set this at the top of your method that handles a request. You might have to do it every time, as you may get a thread per request.
A good place to set it would be in some sort of front controller.