Yea, that looks like a bug. I’ll get it fixed. Dan
> On Apr 13, 2015, at 4:54 PM, Ate Douma <[email protected]> wrote: > > We've noticed a somewhat odd and maybe erroneous difference in how > CXFNonSpringServlet 'restores' the threadlocal CXF bus after being invoked. > > Note: we are using our own dynamic orchestration of CXF, quite similar to the > pattern in CXFNonSpringServlet, so we'd like to know if we should follow the > same approach or maybe better already fix it on our side. > > In CXFNonSpringServlet.java, when invoked as a servlet filter, in method > doFilter the original bus is restored: > > if (origBus != bus) { > BusFactory.setThreadDefaultBus(origBus); > } > > But when invoked as a servlet, in method invoke the original bus is nullified: > > if (origBus != bus) { > BusFactory.setThreadDefaultBus(null); > } > > It seems to make sense and needed to also restore the original bus when > invoked as a servlet, like for example when a (different) filter, also using > CXF but with its own bus, is wrapping the servlet request. > Not restoring the original bus but nullifying as it is done now, might > potentially 'break' this other filter if it still expects its own bus to be > set. > > Or is there maybe a subtle reason behind this different implementation? > > Kind regards, > Ate > -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
