yeah, threadlocal would work. it would also get rid of the need for Session feedback messages. in some sense, i think the error is really being registered for the request (thread) anyway, not any object. so i like that idea. it can just be a threadlocal in the appropriate class and everyone's happy, we actually remove code and component stays the same size. +1
Eelco Hillenius wrote: > >> Apparently the usecase is pretty rare (only discovered after 2 years of >> production use) > > Well, you can't really know as you don't know how many people ever > bumped across this and decided to implement a workaround without > mentioning it to us. More importantly, I just don't think it is right > users cannot do this, and there's a ton of ways to solve this. I agree > with your queue idea, that's the nicest one. > > Eelco > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Wicket-user mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/wicket-user > > -- View this message in context: http://www.nabble.com/error%28...%29-No-page-found-for-component-tf3497125.html#a9773504 Sent from the Wicket - User mailing list archive at Nabble.com. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
