Hi I investigated more about this problem and from a theorical point of view we can't call handle() like proposed. Why? in JSF we have the following phases by default:
RESTORE_VIEW APPLY_REQUEST_VALUES PROCESS_VALIDATIONS UPDATE_MODEL_VALUES INVOKE_APPLICATION RENDER_RESPONSE and we have these methods on FacesContext: renderResponse(); getRenderResponse(); responseComplete(); getResponseComplete(); If a ViewExpiredException is thrown on RESTORE_VIEW, and a call to handle() occur, everything that happens inside the ExceptionHandler is its responsibility. If handleNavigation() is called inside the handler, that handler should check for a view set or getResponseComplete return true and deal with it. Now, if the handler does not do anything, the following phases: APPLY_REQUEST_VALUES PROCESS_VALIDATIONS UPDATE_MODEL_VALUES INVOKE_APPLICATION RENDER_RESPONSE By definition, these phases should check always if there is a view and if it is not, just throw ViewNotFoundException, aborting the current phase. Note it is responsibility of the phase to do the check. In that way the ExceptionHandler could have the chance to handle it. I tried do something different, but it is not possible because is inconsistent with the intention of ExceptionHandler. How can an ExceptionHandler handle exceptions thrown by itself without the risk of get stuck in a loop? regards, Leonardo Uribe 2011/6/27 Leonardo Uribe <[email protected]>: > Hi > > 2011/6/27 Martin Koci <[email protected]>: >> Hi, >> Leonardo Uribe píše v Ne 26. 06. 2011 v 21:29 -0500: >>> Hi >>> >>> I have checked all issues and this is what I think about: >>> >>> - MYFACES-3189 and MYFACES-3188 : I don't see any difference between >>> both of them. >> >> Yes, those are caused by same problem, but I reported it separately >> because MYFACES-3188 suggest only improvement in "robustness" area, >> MYFACES-3189 is about navigation algorithm. >> > > Ok, now I get it. I believe one patch will fix MYFACES-3188 and > MYFACES-3189 should be closed as invalid, because we can really do > anything on the navigation algorithm. > >>> The navigation algorithm is ok. I think with just log a >>> warning message before render response phase saying the view is null >>> is ok. I think it is reasonable to throw a custom myfaces exception >>> here because is viewRoot is null on this point, there is no way render >>> response phase could work. Maybe a ViewNotFoundException? I don't see >>> any incompatibility with the spec, but at least we should notify the >>> EG about this possible problem, because the exception class should be >>> on javax.faces.application, and the algorithm should be clear about >>> this. >>> >> >> Exception: can be this exception also handled with custom exception >> handler? For example: two views (ViewExpired.xhtml and >> NiceErrorView.xhtml) packaged in a .jar. For some reason this archive >> will no be deployed. Then if ViewExpired occurs: >> >> -- exception handler navigates to ViewExpired.xhtml -> >> ViewNotFoundException >> -- exception handler handles ViewNotFoundException and navigates to >> NiceErrorView.xhtml -> new ViewNotFoundException is throw. >> > > Good idea!. The only thing here is we need some special logic to deal with > this. The most difficult problem is we can't keep track of the view > navigations > that cause ViewNotFoundException on the same request, but we can > set a limit of how many ViewNotFoundException can be handled before > jump to the default error page writer. This looks each time more like > something > to be included on the spec. > > regards, > > Leonardo > >> >> >> >>> - MYFACES-3105 : Checked and fixed. >>> >>> Fortunately, there is no errors on the algorithm, but anyway we can >>> expect more reports about ViewExpiredException in the future, because >>> it is a common exception that occur in typical scenarios. >>> >>> regards, >>> >>> Leonardo Uribe >>> >>> 2011/6/26 Martin Koci <[email protected]>: >>> > Hi, >>> > >>> > MYFACES-3189 and MYFACES-3188 are reproducible : please see comment at >>> > MYFACES-3189. The mojara example works ok, thats not the problem. The >>> > problem is when you makes a typo in name of view for handleNavigation >>> > method. >>> > >>> > >>> > >>> > MYFACES-3105 seems fixed in current 2.1.2-SNAPSHOT >>> > >>> > Regards, >>> > >>> > Kočičák >>> > >>> > Leonardo Uribe píše v So 25. 06. 2011 v 11:49 -0500: >>> >> Hi >>> >> >>> >> I have tried to reproduce them without success. I know the navigation >>> >> code and everything seems to be correct. Do you have a test case for >>> >> this one? I tried the bundled sample from mojarra and it works. >>> >> >>> >> regards, >>> >> >>> >> Leonardo Uribe >>> >> >>> >> 2011/6/25 Martin Koci <[email protected]> >>> >> Hi, >>> >> >>> >> please take a look at: >>> >> >>> >> >>> >> https://issues.apache.org/jira/browse/MYFACES-3189 >>> >> https://issues.apache.org/jira/browse/MYFACES-3188 >>> >> https://issues.apache.org/jira/browse/MYFACES-3105 >>> >> >>> >> I'm not very familiar with navigation implementation - I >>> >> cannot provide >>> >> meaningful patches here. >>> >> >>> >> >>> >> Thanks, >>> >> >>> >> >>> >> Kočičák >>> >> >>> >> >>> > >>> > >>> > >>> >> >> >> >
