On Thursday 25 November 2010 11:39:07 am Benson Margulies wrote: > I bet that Dan is his usual overtaxed self, but I'm restarting this > thread to attract his attention, since I fear that I've dug us into a > whole. > > The idea of a default, or thread default, bus in CXF is modelled, in > some respects, on the thread context class loader. However, there's > one big difference. > > A thread has no context class loader until some gives it one. (The > initial thread gets one if you are launched from the java command). > > So, since some piece of code has to take explicit action to put a > reference to a class loader in there, no one can claim to be surprised > if that class loader is protected from GC for the life of the thread > or until someone takes the reference back out. > > Our situation, unfortunately, is more complex, insofar as busses > become default in some rather unpredictable ways. The CXFBusImpl > constructors and the CXFBusFactory call the all-too-accurately named > 'perhapsSetDefaultBus'. > > This seems to me to blow up the distinction I tried to draw in recent > email between implicit and explicit busses. Some piece of code uses > one of them to create an 'interesting' bus. If we hold a hard > reference, then that bus might amount to a memory leak. If we hold a > soft reference, that bus might evaporate out from under them, leading > to a surprise. > > This seems to me to leave us with two choices. (1) undo what I did, > and replace it with a lot of documentation warning people that they > need to be careful to call setDefaultBus(null) or > setThreadDefaultBus(null) to turn off leaks. > > (2) remove the setting of a default bus from the two mechanisms above. > If someone wants to create a bus for themselves, and use it as a > default (as opposed to passing it into the API), they should tell us > so explicitly (via extra booleans in that API). If they don't *ask* > for a default, the default remains null. > > This is fairly conspicuous in the incompatibility dept, all to save > having to tell people to make one or two calls to ensure that CXF > isn't holding a default bus reference that they don't want. So I'm > leaning to (1), but I'd like to hear from Dan and any other concerned > parties.
Honestly, I'm kind of leaning toward #1 as well. If we find places where we are "leaking" things (like in the maven plugins or tooling), we should definitely fix those cases to make sure anything gets set gets unset. -- Daniel Kulp dk...@apache.org http://dankulp.com/blog