Reposting to the list (sorry Martin ;-) in hope for feedback on @RequestScoped Wicket-CDI vs EJB... :
[...about seeting up stuff to propagate user/session/JAAS info from the wicket web layer to a JBoss AS7 EJB...] You can use IRequestCycleListener#onBeginRequest().
Thanks for the suggestion - but I just put the whole JAAS idea in the bin, it's just too much crappy and proprietary code for what it's worth. Now, I just built my own @SessionScoped "call context" in the web layer (Wicket WebPage constructor), and check it with a standard default EJB interceptor at the ejb layer (which @Inject's the "call context"). Since I used SessionScoped, not RequestScoped, all calls in-between the page class (which sets the "call context") like AJAX, onClick()s etc still have the instance from the previous "full page request" available. Is there anything fundamentally wrong with my approach ? Any security issues, race conditions, threadsafety, ... ? There is not too much current info about using Wicket with the lesser known CDI/Weld scope stuff around ... ...@RequestScoped is supposed to work for Wicket6/wicket-cdi-6.4/Tomcat7, right ? (And looks ok, but not heavily concurrently tested of course...) Cheers, Tom. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
