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

Reply via email to