OK, I'll unwind.
On Mon, Nov 29, 2010 at 2:04 PM, Daniel Kulp <dk...@apache.org> wrote: > 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 >
