Well, you guys can do what you want with the release. It's your baby. I'm giving up my argument because it really doesn't matter to me (I'll just wait for the later release when this is backed out) and my vote doesn't "count" anyway. I don't know that I would necessarily -1 anyway if I could. I would probably be -0. I don't think it should be released with something in it that you know you're going to back out in a later release. Apparently that's just me, though.
On Thu, May 20, 2010 at 9:19 PM, Jeremy Thomerson <jer...@wickettraining.com> wrote: > That's actually part of what I'm saying. Right now, if you start a thread > for AppA from a request in AppB, you are *not* using Application.get(). You > *must* be passing the Application in some way to the thread. So, this > doesn't break that functionality. What I was saying about what's "already > broken" is if you are inadvertently starting a thread for AppA in a request > from AppB, that's currently a bug, and nothing we're doing will either make > that better or worse. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Thu, May 20, 2010 at 7:40 PM, James Carman > <ja...@carmanconsulting.com>wrote: > >> That's not an existing problem because the application threadlocal isn't >> propagated to the pooled thread. >> >> On May 20, 2010 6:39 PM, "Jeremy Thomerson" <jer...@wickettraining.com> >> wrote: >> >> You would only get an Application in a thread that was started from a >> request thread. You wouldn't start a thread for AppB from a request in >> AppA. The only chance of getting that cross-over would be if you started >> threads in AppA that were later pooled for AppB - but that would be an >> existing problem. >> >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> On Thu, May 20, 2010 at 5:22 PM, James Carman <ja...@carmanconsulting.com >> >wrote: >> >> >> > What if someone has two applications running in the same webapp that >> > are handling two different... >> >
