I have a question about handling org.apache.shiro.cache.CacheException.
What is shiro's responsibility when a cache exception occurs? This RTE ripples through the whole stack, but I'm unclear where it is handled and in what manner.
Can a shiro enabled web application recover?
Is the cache manager reinitialised?
Do I have to restart the application when a cache exception occurs?
For example, a timeout exception or a failed to connect to node exception occurs on cache.get(key). What's the expected outcome apart from bubble to the stop and die?
Thanks
I have checked all usages of CacheException and the only thing shiro does is throw it. It never gets catched let alone handled.
So the only expected outcome is to "bubble to the stop and die".
What you can do about it is have a servlet filter in front of shiro that catches this exception, then get a hold of the CacheManager instance (how you do that depends on your setup) and call cacheManager.getCache().clear() so the cache is reset.
Related
I was seeing this exception in the logs intermittently when executing the order flow. Not sure why the system is being thrown
org.springframework.web.servlet.handler.SimpleMappingExceptionResolver - Resolving exception from handler [org.springframework.webflow.executor.mvc.FlowController#217e2228]: org.springframework.webflow.execution.repository.NoSuchFlowExecutionException: No flow execution could be found with key '_c733263A4-6F01-E222-AA1D-05475DFE4197_k7F1228F0-709E-EC90-6ABC-DC489BEFD7B5' -- perhaps this executing flow has ended or expired? This could happen if your users are relying on browser history (typically via the back button) that references ended flows.; nested exception is org.springframework.webflow.conversation.NoSuchConversationException: No conversation could be found with id '733263A4-6F01-E222-AA1D-05475DFE4197' -- perhaps this conversation has ended?
Does anyone have idea when the spring frame work throws this exception.. How to resolve this ..
This could happen if the container session expires. The following request would create a new session which would not contain the flow and conversation from the previous session. So when the request processing looks for the flow or conversation it throws that exception.
An easy fix might be to increase the session timeout on your servlet container...
For exceptions thrown while handling a request, Spring has a number of different ways to register exception handlers. Is there a way to apply similar exception handling when the exception is thrown while rendering a view? At a minimum I'd like the ability to perform some logging.
The problem is that exceptions thrown during View rendering cannot do an awful lot. In particular, they typically can't render a HTML page containing an error report ... or even send a 5xx response ... because the response will typically have "committed" before the exception is thrown.
So the best you can do (probably) is:
create a wrapper for the View object that catches and logs the exception, or
do the logging in a servlet filter,
But the chances are that the web container can be configured to log uncaught exceptions anyway.
UPDATES
I just noticed spring's HandlerInterceptor class exposes an 'afterCompletion' method which will be invoked when exceptions are thrown. Any thoughts as to the benefits of using this vs. a filter?
Try it and see. :-) But given the following, I doubt that it will work.
Using a filter or interceptor does not work for exceptions thrown while rendering a jsp. It does print to err out:
Dec 16, 2012 12:18:03 PM org.apache.catalina.core.ApplicationDispatcher
invoke SEVERE: Servlet.service() for servlet jsp threw exception
javax.el.PropertyNotFoundException: Property 'fooo' not found on
type java.lang.String"
Unfortunately the exception is not propagated upwards to the filter. I'd like to add my own logging which sends out error notifications and logs additional information about the failed request. Keeping an eye on log files to spot errors isn't a good option.
The chances are that the log message is actually produced using the logging subsystem. If it is, you can use the logging configuration to add your own handler for JSP engine logging events and send out special notifications.
The fact that the exceptions are 1) being thrown during JSP view rendering, and 2) the JSP engine is not propagating them means that (IMO) it is unlikely there is a way for you to catch them.
The other option is to set up a scanner for the log files ... as part of your general system monitoring.
in my application (using spring),
i try to call a method from view using spring exposingBean. and when i try to invoke a method from view, it throw error. i try to catch with HandlerExceptionResolver, but no luck, i think it cannot handled by HandlerExceptionResolver because exception wasn't thrown to controller.
so i try another way to redirect the request when exception thrown. and i think aspect has possibility to do it. is it possible to redirected request when exception thrown from aspect?
As you rightly say, HandlerExceptionResolver will not be invoked when an exception is thrown from inside the view. These resolvers are very specifically targetted at controller exceptions.
Your best options here are to use either a HandlerInterceptor and override the afterCompletion method, which will contain the exception thrown by the view. You may be able to send a redirect from here, dependning on whether or not the response has already been committed by the view.
I don't see how aspects would help you here, either. Not the tool for this job.
However, my advice to you is to stop using exposed bean in your JSP. I realise that it's temptingly convenient, but this is the sort of trouble you get from using it. I advise that your controller assemble all the data required by the view, stick it in the model, and send it to the view. That way, there's less danger of the view triggering an exception, since it already has everything it needs.
Also, if you need to send a redirect, as you do, then you really need to do this before the view starts executing. Otherwise, the view layer may start writing out the HTTP response headers before the exception is thrown. If this happens, then you won't then be able to send a redirect instead - the response is "committed".
There is a task of managing desktop client session status:
Ensure only single client is "connected".
Force client logout - kill session.
Kill client session on timeout due to inactivity.
Server-side is JBoss and EJB3. How to achieve such task?
You can use Singleton Pattern here, once initialized, deny subsequent requests thereafter in synchronized method by using delegate to access interfaces (local/remote).
Maintain you own idle-timer & start it at event occurence either mouse/key for your window.
On timeout, you can de-reference the initialized objects & redirect to login.
Method annotated with #Remove allows to kill EJB3 session.
We can ensure uniqueness of session by adding it to static (or other unique) container and check for existence before returning it for the new client. If existing session found, we throw an exception for the user.
So, this answers my questions, I think.
I have some EJBs that use Hibernate to persist data to the database. I have a thick Swing client that talks to these EJBs. The client knows nothing about the database (no driver jar).
During one transaction a Hibernate ConstraintViolationException can be thrown. I catch all exceptions and wrap them in an EJBException like so:
catch(HibernateException e) {
e.printStackTrace();
throw new EJBException(e);
}
The problem I am getting is that when the exception is unmarshalled by the JBoss Invoker on the client side, a ClassNotFoundException is thrown (for PSQLException) since the client has no sql driver jar in the classpath.
I changed this application to always pass the caught exception to the ejbexception constructor like this so we could have a stack trace history. Now I am finding why the original developers didn't do this.
At this point I see two options - either include the postgres driver jar with the client, or remove passing the caught exception to the EJBException constructor. I am curious if anyone has any other suggestions and also how others handle exceptions in their EJBs?
My take is that the client, end user, doesn't need to know the technical details of the problem. Hence at various layer boundaries it's quite reasonble to convert a technical exception to a general "An error of nature XYZ ocurred".
A scheme I've seen used is for the server to allocate a unique error number at the point the exception is detected. It then writes diagnistics to its logs including that number. Messages reported to the client simply include the number. A support desk can then correlate the user's report of the issue via that specific error number.