Sounds good - probably better to put that back in until we can figure out a way to resolve this more cleanly.
On Fri, Feb 19, 2010 at 12:21 PM, Kalle Korhonen <[email protected]> wrote: > Quick feedback cycle, that's good :) My changes yesterday broke this. > Given that getSubject() currently currently checks if Subject exists > in ThreadContext before creating a new Subject, we should bind the > newly created Subject back to the thread - going to check this in > unless I hear otherwise. We are discussing the conceptual changes on > the dev list but it'll take longer to reach any agreement. > > Kalle > > > On Fri, Feb 19, 2010 at 8:11 AM, aloleary <[email protected]> wrote: >> >> Ok that's pretty much what I figured - just wanted to be 100% certain as >> things suddenly stopped working and thought it might have been on my side.. >> >> I think in my particular case it's ok for me to manage as it is a client >> application running in either Swing or JavaFX with a java/spring/shiro core >> layer... >> >> JavaFX/Swing apps need strict thread management as they are inherently >> single threaded on the presentation side - but there can be many >> background/worker threads. >> >> Here I can use both of the following to allow me to use shiro in my case: >> >> ThreadContext.bind(currentUser); >> currentUser.associateWith(callable) >> >> So the UI which has a reference to the Subject can always call associate >> with if it fires off background thread(s) >> >> Do you see any issues with this ? I assume using >> currentUser.associateWith(callable) is still ok ? >> >> Thanks >> -A- >> >> >> >> -- >> View this message in context: >> http://n2.nabble.com/SecurityUtils-getSubject-issue-tp4597560p4598657.html >> Sent from the Shiro User mailing list archive at Nabble.com. >> >
