[EMAIL PROTECTED] wrote on 10/14/2005 02:51:05 PM: > > > > The implication of this sequence of events is that the navigation requested > by "unauthenticated" did not actually happen, so it's redisplaying the same > page again. Are you sure you've got the navigation rules set up correctly, > so that this navigation should actually fire?
Hey no kidding, I actually thought of this :) and double checked my faces-config.xml (case sensitivity and all) and I am quite sure not only that "unauthenticated" is in fact what the logoff method returns and that it is mapped to /failure.jsp > > It might also be useful to experiment with a case where worklist.jsp is just > a simple JSP page and not something with Tiles in it, just to make sure > that's not part of the problem. and yuk, I did think that tiles could be part of the problem too - though I *really* don't want that to be the case..(:(. Along these lines, when I read about the various times when preprocess() etc. get called, it seems like words like "the view id" and "the view" and "the jsp" and "the backing bean" are all used interchangably. Which is ok; i remember you telling us jsp<->backing bean is a 1:1 relationship. Fine. But do you "calculate" what the jsp/bean are (to decide what is A and what is B, for instance during a "postback from page A to page B" using the mappings in faces-config.xml? Because that is how I did it: logon page -> worklist page -> logoff page. Hence beans are LogActionBean, WorklistBean, LogAction bean. (Tiles makes the urls wierd but that should not be the way things are calculated right?) > > Craig > > --
