I've encountered a strange problem in a Grails webapp running under Grails:
java.io.UnsupportedEncodingException is thrown quite frequently due to various unknown encoding strings (such as "ISO8859_10", "ISO-8859-10"), and the strange thing is that this is done entirely within the Resin and Grails code. That is - no custom code is involved when the exception is thrown.
I'm not sure if it is Grails or the servlet container's code that should handle the exception. But I'd assume that the exception should be handled somewhere and not bubble up all the way to stderr.
This is the exception in full:
java.io.UnsupportedEncodingException: ISO-8859-10
at com.caucho.vfs.i18n.JDKWriter$OutputStreamEncodingWriter.<init>(JDKWriter.java:112)
at com.caucho.vfs.i18n.JDKWriter.create(JDKWriter.java:79)
at com.caucho.vfs.Encoding.getWriteEncoding(Encoding.java:231)
at com.caucho.server.connection.ToByteResponseStream.setEncoding(ToByteResponseStream.java:137)
at com.caucho.server.connection.AbstractHttpResponse.setLocale(AbstractHttpResponse.java:1683)
at com.caucho.server.connection.HttpServletResponseImpl.setLocale(HttpServletResponseImpl.java: 115)
at javax.servlet.ServletResponseWrapper.setLocale(ServletResponseWrapper.java:139)
at javax.servlet.ServletResponseWrapper.setLocale(ServletResponseWrapper.java:139)
at org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1035)
at org.codehaus.groovy.grails.web.servlet.GrailsDispatcherServlet.doDispatch(GrailsDispatcherServlet.java:290)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:114)
My questions:
Should the exception be handled? If so, is it the responsibility of the servlet container (Resin) or the web framework (Grails)?
How would you go about solving this? (I'd rather not having the exception log cluttered with exceptions that I can do nothing about.)
I don't know much about Grails, but maybe you could try to find out where this weird encoding comes from.
Do your requests send Accept-Charset headers?
Do things work better if you set the "file.encoding" system property to something meaningful like UTF-8 in your resin.conf?
You can also set up a localeResolver bean in your application context. The DispatcherServlet will use that to resolve the locale. I haven't tried it myself, but my suggestion is to use the org.springframework.web.servlet.i18n.FixedLocaleResolver. It will delegate to Locale.getDefault() if you don't have any set up.
Related
I am using Apache Camel Framework and going through the documentation regarding the error handling , i am confused between Exchange.ERRORHANDLER_HANDLED and Exchange.FAILURE_HANDLED properties
Exchange.ERRORHANDLER_HANDLED: As per my understanding this property is to propagate the exception back to caller.
but not able to find any information Exchange.FAILURE_HANDLED on this.
Those are internal flags and should not be in-use by end users.
The Jersey documentation explains how to convert an Exception to a Response, but it fails in detailing what will happen if my code throws an Exception that isn't mapped or derived from WebApplicationException.
This link says:
If the thrown exception is not handled by a mapper, it is propagated and handled by the container (i.e., servlet) JAX-RS is running within.
But this only explains how JAX-RS 2.0 is supposed to behave in general terms and not how Jersey, which is the container in this case, is going to handle this Exception.
I know some people will just say Well, why don't you try it out and see what happens?... and the answer is: Because I like to know the documentation and I try to avoid empirical results, since they can be contaminated with coincidences and exceptional cases.
So, the question is:
How Jersey deals with not mapped Exceptions, like SQLException or IllegalArgumentException? Exceptions that are thrown by one of my Resources and not handled by my code.
Jersey is always deployed somewhere. Usually, it's a servlet container (in an application server or Tomcat for instance), but in Java SE only environment it can be for instance Grizzly or even JDK HTTP server. See documentation for deployment options.
What happens to exception uncaught (or thrown) by Jersey is up to this deployment environment. For instance, the servlet container usually catch the Exception, logs it and returns http status 500.
I have a ServletContextListener which performs some database management functions when my Java EE application starts. This runs in my application before JPA and other pieces of the application are started/loaded. If the database maintenance fails I am logging the errors. If the database maintenance fails the application will not function properly and I would like to halt the application.
How can I gracefully and correctly stop the application from ServletContextListener.contextInitialized?
Solution given by Viven below is close but not quite. When I throw a RuntimeException Glassfish is left in an inconsistent state where its admin console is not accessible but some process is still running and keeping port 3700 (IIOP?) open which then prevents a restart.
In your listener, catch any exceptions and use servlet context attributes to store flags or other useful information about the error. You should probably also log something to indicate that the app is non-functional.
At this point, your options may be dictated by the architecture of your app. If all requests are handled by a single controller/dispatcher servlet, it might make sense to have its init method check the context attributes and throw an UnavailableException. Just be aware that the exception only applies to the specific servlet throwing it. This makes the approach less manageable if your app contains many servlets or allows direct access to other resources.
Another option would be to create a filter that intercepts every request, checks the context attributes and then throws an exception. Other variations are certainly possible.
If your ServletContextListener throws an exception, the webapp won't load correctly and the application server may block all subsequent request (and respond with a 500 error).
It isn't exactly preventing the application to start, nor stopping the application, but it prevents any further usage of the app and could be useful in your case.
After proper verification in the spec, this behaviour isn't mandatory in the specification. The server may (not must) return 500 errors. This solution has to be used carefully, therefore.
See this Answer for a quote from the Servlet spec.
I am trying to send mail in my web application. I am using the libraries javax.mail-1.4.4 and activation-1.1. My configuration is set up like described in the Tomcat Docs here http://tomcat.apache.org/tomcat-5.5-doc/jndi-resources-howto.html#JavaMail_Sessions
The web.xml file is configured properly according to this information. The context.xml where I store the settings is configured properly as well (or at least should be) with mail.*, auth, name, type info set properly.
When trying to send a mail this way, I get the following error:
Exception in thread "Thread-27" java.lang.NoClassDefFoundError: javax/mail/Authenticator
in this line:
session = (Session) envCtx.lookup("mail/Session");
I've looked through some solutions, like missing mail/activation libraries, checked up on those but none I could find were able to help me. Any idea what I could do to fix this or get in closer on the error?
"should be" is the operative phrase. I'd recommend that you believe Tomcat when it tells you it's missing things. You have not configured things properly until Tomcat says you have.
I'd recommend that you put them into the Tomcat /lib folder and see if that makes a difference.
I am migrating my Seam 2 powered application to CDI and one of the things that is critical for me to retain is the error handling. In Seam 2, I simply replaced the default exception handler with my own, but in CDI, I am guessing I'll have to use an Interceptor.
How would I set this up as using an Interceptor requires me to specify where it will intercept calls? I mostly want to accomplish auditing, so when an exception occurs, it is logged, then a notification (email, xmpp, sms, phone call) is sent out to administrators.
When an exception occurs, is there simply an event that I can listen for and act on?
Walter
Are you using JSF2? If yes, instead of writing an Interceptor, you could register an ExceptionHandlerFactory in your web.xml as described here. In a CustomExceptionHandler, you can catch all Exceptions and handle them programmatically.
I'm using this approach in my JEE6-CDI-app, find it quite okay.