That's the thing - we haven't even discussed IF we would back it out in a future release. Has anybody given *any* evidence that this actually breaks something that wouldn't already be broken? If someone does, I'm fine with backing it out. But, we don't think it will break any existing applications, so there's no reason to waste the effort that already went into this release. Why throw away all of the other enhancements* for the sake of this non-broken thing that people have unfounded exception to?
* including the big performance gain in the broken injector, which is WICKET-2875 - not explicitly mentioned in the release notes because I overlooked it since it was closed as duplicate to WICKET-2741 -- Jeremy Thomerson http://www.wickettraining.com On Thu, May 20, 2010 at 8:28 PM, James Carman <ja...@carmanconsulting.com>wrote: > 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... > >> > > >
