I have error_messages table, which contains the site-wide error messages.
I use the error messages across application. So, I created singleton bean of error messages (ErrorMessagesLoad.java)
ErrorMessagesLoad uses ErrorMessageDao to retrieve the error messages from database.
Should I create static variable in ErrorMessagesLoad to hold all the error messages and use it in all classes? or is there better way of doing it?
Thanks,
Satya
You should use your own implementation of MessageSource in Spring to resolve any messages. Here is a good point to start.
When implemented, you just wire your bean to any service or controller and it handles messages for you, with ability to iternationalize them.
In general global static variables should be avoided. Error handling can get tricky. Many applications try to put a global catch handler somewhere near the top (e.g. web applications the top would be filters) which has the ErrorMessagesLoad injected into it. That handler catches underlying exceptions, translates them into something user readable and then throws that higher.
Some examples include Spring's exception translation filter and Jersey's exception mapping mechanism.
Related
In my Dropwizard project, I'm defining a generic ExceptionMapper<WebApplicationException>:
environment.jersey().register(new WebApplicationExceptionMapper());
...but this doesn't seem to catch any of the 404 errors for unmatched paths.
Without defining five defaultHandler() methods for every single resource, how do I catch all 404s so I can return my own error page or some JSON?
So, if I had a service with one resrouce, say, /docs, this is the situtation:
/myservice/docs/helloworld doesn't match any #Path defined in my DocsResource. It returns a generic Jetty 404 page (not what I want)
/myservice/doesntexist returns my own error resource with the exception mapper (this is what I want everywhere)
what you need to do is to set a different Error handler. The 404's you are seeing when hitting a non-existing path, are not handled by jersey. Jersey maps exceptions for resources, but you in fact never hit the resource in the first place. This is where you will need to define an error handler:
In DefaultServerFactory, you need to overwrite:
protected Server buildServer(LifecycleEnvironment lifecycle,
ThreadPool threadPool) {
final Server server = new Server(threadPool);
server.addLifeCycleListener(buildSetUIDListener());
lifecycle.attach(server);
final ErrorHandler errorHandler = new ErrorHandler();
errorHandler.setServer(server);
errorHandler.setShowStacks(false);
server.addBean(errorHandler);
server.setStopAtShutdown(true);
server.setStopTimeout(shutdownGracePeriod.toMilliseconds());
return server;
}
(This class is in AbstractServerFactory).
You then can implement your own ErrorHandler and make it do whatever it is you want it to do.
For testing, open org.eclipse.jetty.server.handler.ErrorHandler and set a breakpoint, then try and hit a non-existing URL. It will stop there and you can see how jetty handles this sort of thing.
I hope that helps.
If you need help overwriting default DW functionality, you can look at a similar post where I described how to overwrite loggers:
Dropwizard doesn't log custom loggers to file
Cheers,
Artur
Consider a Person entity with a property name that is annotated as #NotNull. Then a simple PersonRepository and this repo exposed with Spring Data Rest.
When I POST to create a new Person, if the name property is null a ValidationException occurs as expected. But what I actually get on the client is an Internal Server Error (500) and the message is a TransactionSystemException that happened much later in the exception chain.
What I'd expect to get is a Bad Request (400) with the actual ValidationException and all it's useful information so the client can know what's wrong with the posted data.
There seems to be a way to attach custom validators with SDR as explained here. But the thing is, this is not a custom validator, it's a standard bean validation that happens when the repository is asked to save data. So I'm not really sure how those two come together.
So questions:
What are my options to let the client know what's wrong with the submitted data when using SDR?. Things like what fields are invalid and what's the error for each field would be awesome.
Are there any examples about this anywhere?
Thanks a lot.
What you need is a proper ExceptionHandler, it will handle back end exceptions and send meaningful rich messages (json/xml) to the front end client.
Take a look a this git repository
This question is regarding Atmosphere framework.
I am trying to broadcast a message to clients as soon as any event occurs (i.e. Notification).
I am not able to get Hazelcast broadcaster to work for publishing data from server to cliens. I tried using following hazelcast broadcaster implementation (atmosphere-hazelcast-2.3.0-RC5.jar).
https://github.com/Atmosphere/atmosphere-extensions/blob/master/hazelcast/modules/src/main/java/org/atmosphere/plugin/hazelcast/HazelcastBroadcaster.java
Atmosphere automatically detects atmosphere-hazelcast-2.3.0-RC5.jar file when put in classpath. Hazelcast instance starts properly when I start my Tomcat 7.
But as soon as a call is made to factory.lookup(uniqueId) to lookup for topic to broadcast message, I get following exception:
Exception in thread "Thread-3" java.lang.IllegalStateException: Invalid lookup class org.atmosphere.plugin.hazelcast.HazelcastBroadcaster. Cached class is: org.atmosphere.cpr.DefaultBroadcaster
I am getting the broadcaster object as follows:
AtmosphereFramework framework = (AtmosphereFramework) getServletContext().getAttribute("AtmosphereServlet");
BroadcasterFactory bf = framework.getBroadcasterFactory();
Broadcaster b = bf.lookup(uniqueId);
Is this the correct way to get the broadcaster in a simple servlet or one must use #Inject to inject broadcaster? (In case of simple servlet I am not sure how to use #Inject to inject a broadcaster).
Note that if I do not use HazelcastBroadcaster, then factory.lookup(uniqueId) call works well (Using default broadcaster) and messages are sent to client.
Has anybody faced similar issue? Will appriciate any pointers to solve this.
Thanks !
Looks like a bug to me with 2.3.x-RCx. Please file an issue https://github.com/Atmosphere/atmosphere
-- Jeanfrancois
I am new to JSF and struggling with a problem. I am hoping that someone can help me.
Problem:
A handler that is not a bean detects a message from a TCP/IP pipe.
The handler needs to create a new FacesMessage to display the message in a message box.
Since the handler is not a bean, FacesContext returns null, therefore the handler cannot write the FacesMessage.
Questions:
Is it somehow possible to do what I am trying to do?
What is the best way to propagate an external message from a Java class that is not a bean to a FacesMessage so that it is displayed on the UI?
Any ideas on how to resolve this?
The FacesContext.getCurrentInstance() method only returns a valid faces context if you're in an actual faces session. I think what you should be looking at doing is architecting this such that your class that does the TCP/IP message handling provides a means for a faces managed bean to get information about the messages to the front end, and then accessing that method from a managed bean.
Depending on what type of application server you're using, you may want to set this whole thing up to interact through an EJB session bean. But really any backing bean or faces logic should absolutely be separate from logic unrelated to your UI.
If you're using a JEE6 compliant application server (like Glassfish) you could set up an #Singleton EJB to hold a set of messages (be sure to use a data structure that supports concurrency) and something like JCA-sockets (http://code.google.com/p/jca-sockets/) to handle the socket communication.
No, it is not possible, alternative way is to create backing bean either by #ManagedBean annotation or by having entry in faces-config.xml like
<managed-bean>
<managed-bean-name>bean</managed-bean-name>
<managed-bean-class>com.test.bean</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
and now you can get facesContext and create FacesMessage both, hope this helps.
My code is throwing an exception (due to a bug). In the log, I see:
org.jboss.resteasy.spi.UnhandledException: java.lang.NullPointerException
at org.jboss.resteasy.core.SynchronousDispatcher.handleApplicationException(SynchronousDispatcher.java:323)
at org.jboss.resteasy.core.SynchronousDispatcher.handleException(SynchronousDispatcher.java:199)
at org.jboss.resteasy.core.SynchronousDispatcher.handleInvokerException(SynchronousDispatcher.java:175)
at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:529)
etc...
The stack of the actual exception is not logged. If I wrap my code in a try..catch and log the caught exception I can verify that my code is at fault. No other library in my system does this, even for deeply-wrapped exceptions, so it must be a problem in RESTEasy, perhaps in UnhandledException?
Is there a way to get around this behavior? I can't think of a good reason why it should be hiding the actual exception.
Jetty
Java
Spring 3.0.3
RESTEasy 2.0.1GA
Do you have an ExceptionMapper? See Chapter 27, Exception Handling, in the RESTEasy documentation.
I used RESTEasy to add REST to an existing system, and the existing system has a weird way of wrapping exceptions within exceptions, so my ExceptionMappers do a lot of unwrapping.
Throwable t = exception;
while (t.getCause() != null) {
t = t.getCause();
}
t.printStackTrace();
I don't use RESTeasy, but it appears to be a dispatch mechanism for RESTful web services.
Assuming this is the case, then it has different design goals from other libraries: they are invoked from your application, but RESTeasy is responsible for invoking your application. It therefore has to protect itself from poorly written code. A "last ditch" exception handler is a common way to do this; you'll see the same thing in Swing.
Whether or not it should log the uncaught exceptions is a different matter. Perhaps there's a configuration option to do this. Or perhaps you need to add a couple lines of code. It is open-source, after all, and I'm sure the maintainers would appreciate a well-written bug report with patch.
Yes, your exception is swallowed by RESTeasy, wrapped in UnhandledException and logged. But your exception lies too deep within to be included in the stacktracs.
To print out your exception to the console, you could append the following to 'WEB-INF/classes/logging.properties'
org.apache.catalina.core.ContainerBase.[Catalina].level = FINEST
org.apache.catalina.core.ContainerBase.[Catalina].handlers = java.util.logging.ConsoleHandler