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 >> >> >> >> >> > >> > >> > >> > > >
