[orbit-dev] Buddies for Buddy Classloading?

[David M Williams <david_williams@xxxxxxxxxx>]

I'm hoping there's some classloader
experts on this list that can give a quick definitive 
solution to a blocking problem. 
I've opened orbit bug 186489 because
of bug 186262

https://bugs.eclipse.org/bugs/show_bug.cgi?id=186489
https://bugs.eclipse.org/bugs/show_bug.cgi?id=186262

We (in WTP) used to solve this class
loader problem by putting log4j in the manifest.mf file
of commons.logging, so commons.logging
API could find the log4j class on it's own classpath. 
But .. that doesn't seem quite right.


As best I can tell, the right way to
do this is to put 
Eclipse-BuddyPolicy: registered
in org.apache.commons.logging. 

Then in log4J, put 
Eclipse-RegisterBuddy: org.apache.commons.logging

But, seems all the examples I can find,
put 
Eclipse-BuddyPolicy: registered
in log4J and then in yet some 3rd plugin
put 
Eclipse-RegisterBuddy: org.apache.log4j
(and, these examples never use or mention 
commons.logging). 

So ... does this sort of "transitive
solution" look right? Where log4j is 
both registered and allows registry.


BTW, part of the problem is that we
(WTP) are not really using these loggers, 
.... so we don't know how to test it
... 
we are just trying to satisfy the classloading
constraints designed into 
third party libraries, such as axis,
and others. 

Advice welcome.