Correct, there should not be thread locals leaking between requests.
On Wed, Jan 30, 2013 at 1:51 PM, todor.dimitrov <[email protected]> wrote: > Just to be clear, this is not the expected behavior, right? The code should > be working as is? > > Thanks for the prompt response, > > Todor > > > On 30.01.2013, at 19:45, Joseph Bergmark <[email protected]> wrote: > >> I would be surprised if it was randomly grabbing another session. >> >> My guess is that either the WebContextService threadlocals are leaking >> the contexts themselves, or the threadlocal where we hold onto the the >> request in order to lazy initialize the session is leaking, otherwise >> I would expect you would receive a ContextNotActive exception if >> Session was active on the current request thread. >> >> Sincerely, >> >> Joe >> >> On Wed, Jan 30, 2013 at 12:53 PM, todor.dimitrov <[email protected]> >> wrote: >>> Another follow up, >>> >>> if I add >>> >>> ((HttpServletRequest)request).getSession(true) >>> >>> at the beginning of the the doFilter method, then everything works as >>> expected and the previously described behavior is never observed. This means >>> that whenever the CDI implementation (OpenWebBeans) cannot retrieve the >>> session of the current web request, it injects a wrong object (i.e. an >>> object belonging to another session). >>> >>> >>> On 30.01.2013, at 17:55, "todor.dimitrov" <[email protected]> wrote: >>> >>> Hallo again, >>> >>> I've just noticed that when this behavior is observed the session associated >>> with the HTTPServletRequest is null. Somehow Tomcat cannot create a session >>> object for the request (normally a StandardSession object is associated with >>> the request). IMHO CDI shouldn't inject an object instance from some other >>> session if the session of the request is null. >>> >>> >>> >>> On 30.01.2013, at 17:39, "todor.dimitrov" <[email protected]> wrote: >>> >>> Hallo, >>> >>> I have a weird problem when injecting a bean inside a servlet filter, which >>> is produced by a method of a session-scoped bean: >>> >>> Filter: >>> >>> public class AuthenticationFilter implements Filter { >>> >>> @Inject >>> @LoggedIn >>> private Instance<User> loggedInUser; >>> >>> public void doFilter(ServletRequest request, ServletResponse response, >>> FilterChain chain) throws IOException, ServletException { >>> >>> final User user = loggedInUser.get(); >>> if (user != null) { >>> // proceed ... >>> } else { >>> // redirect to login ... >>> } >>> } >>> >>> ... >>> } >>> >>> Session-scoped bean with producer method: >>> >>> @Named >>> @SessionScoped >>> public class Login implements Serializable { >>> >>> private User currentUser; >>> >>> public String login() { >>> currentUser = loadUserFromDB(...); >>> } >>> >>> public String logout() { >>> currentUser = null; >>> } >>> >>> @Produces >>> @LoggedIn >>> public User getLoggedInUser() { >>> return currentUser; >>> } >>> } >>> >>> Qualifier: >>> >>> @Target({ ElementType.FIELD, ElementType.METHOD }) >>> @Qualifier >>> @Retention(RetentionPolicy.RUNTIME) >>> public @interface LoggedIn { >>> } >>> >>> Sometimes the filter incorrectly retrieves the user instance from some other >>> active session. This happens, however, only the first time the page is >>> requested by the browser. On subsequent page reloads, the filter recognises >>> that the user is not logged in. It should be noted that the JSF >>> implementation (MyFaces) ALWAYS uses the correct instance of the >>> session-scoped bean. I've tried to inject the Login bean instead of the User >>> object but the result is the same. >>> >>> Do you have any clues to why I might be experiencing such a behavior? >>> >>> >>> Thanks in advance, >>> >>> Todor >>> >>> >>> >
