{"push_id":2874247568,"size":1,"distinct_size":1,"ref":"refs/heads/master","head":"3febfb2b6867088dc51dbc4650e67423dbeeec47","before":"10a61891f45dd1a2c8b1d9a44ae19dd7f7899cc3","commits":[{"sha":"3febfb2b6867088dc51dbc4650e67423dbeeec47","author":{"name":"snowjak88","email":"ffa4e7ff7061bad8917c4579c18d7bc2b6fbc67f@gmail.com"},"message":"Fixed bugs in ObjectCreator component and our use of Spring Security.\n\nObjectCreator -- the constructor was calling setClass(...) on itself. Moved this call to a @PostConstruct method.\n\nSpring Security -- we were getting errors where:\n 1) the user would log in\n 2) this would trigger a SuccessfulLogin message\n 3) when a suitable message-handler would try to get log-in details, it wouldn't find any\n\nThis problem would disappear if the user then logged-out and -in.\n\nThe problem was caused by the EventBus spawning worker-threads (because we're using the AsyncEventBus subclass), and those worker-threads wouldn't have access to the just-configured Spring SecurityContext (because that SecurityContext is stored in a ThreadLocal SecurityContextHolder).\n\nThe solution was to extend the ThreadPoolTaskExecutor we're supplying to the AsyncEventBus.\n - each submitted task is supplied with the calling thread's SecurityContext before being passed to a new Thread.\n\n...\n\t@Override\n\tpublic void execute(Runnable task) {\n\t\tfinal var auth = SecurityContextHolder.getContext().getAuthentication;\n\t\tsuper.execute(() -> {\n\t\t\tSecurityContextHolder.getContext().setAuthentication(auth);\n\t\t\ttask.run();\n\t\t});\n\t}\n...","distinct":true,"url":"https://api.github.com/repos/snowjak88/rays/commits/3febfb2b6867088dc51dbc4650e67423dbeeec47"}]}
{"actor":{"display_login":"snowjak88"}}