So now that a Spring fix is out that code should probably be tweaked so that a portlet parameter can be set to toggle behavior. It is the version of Spring that the portlet is using that dictates the spring controller's exception handling behavior.
-Eric On 07/16/2013 10:24 AM, Anthony Colebourne wrote: > Hi, > > The problem is we're forced into manually trapping all exceptions that > occur during an action request or face the user with a not so helpful > generic error. > > I see that this was fixed in spring, so is the intention that this > will be removed from uPortal at some point? > > I cannot get my head around whether the workaround is needed to > accommodate the version of spring in uPortal or the version of spring > in portlets? > > -- Anthony. > > > > > On 16/07/13 16:05, Eric Dalquist wrote: >> Take a look at: https://issues.jasig.org/browse/UP-3408 >> >> Perhaps this needs to be a toggle for exceptions during actions but we >> were seeing issues where portlets were failing but the portal didn't >> correctly respond to the failure due to spring swallowing the exception. >> This was particularly bad for Events where a portlet may never even >> render after an event exception effectively hiding the exception >> completely. >> >> -Eric >> >> On 7/16/13 9:29 AM, Anthony Colebourne wrote: >>> Hi, >>> >>> We've been working on an issue where we are throwing an exception >>> within the Action phase of a portlet. This portlet is using Spring >>> 3.2.0. >>> >>> The problem we're seeing is that the ExceptionResolver is not picking >>> up the exception. >>> >>> It seems that in our version of Spring, this should work. However it >>> seems that this commit on uPortal prevents it from working. >>> >>> https://github.com/Jasig/uPortal/commit/f55dc7d488e96d9cc7e2081167c0e7cfea404ca1 >>> >>> >>> >>> Can anybody shed some light on the situation? >>> >>> Thanks, >>> Anthony. >>> >> >> >
smime.p7s
Description: S/MIME Cryptographic Signature
