Igmar, Because of these two problems I still believe it would be better for your bundle X to call directly to the LogService rather than going through the intermediary Y. I don't know exactly what value Y is adding, perhaps making it more convenient to lookup the LogService? But it should be possible to allow Y to access the LogService using X's BundleContext, thus making the logging calls appear to come from X.
Regards, Neil On Wed, Nov 3, 2010 at 2:37 PM, Igmar Palsenberg <[email protected]> wrote: > > Hi Jeff, > >> - in Y walk down the stack the number of frames you are from the real logger >> (e.g., X calls Y directly, look down one or two frames). >> - Get the classloader for the method running in that frame. >> - If you are on a recent framework then that classloader may well be a >> org.osgi.framework.BundleReference. If it is, cast and call getBundle(). >> - carry on >> >> For some sample stack walking code, look at Equinox's >> ContextFinder.basicFindClassLoaders() method [0]. > > A problem with that is that the stacktrace doesn't give me bundle > information. If you have 2 bundles with the same class Foo(), you don't know > which bundle that Foo in the stacktrace refers to. You only get a name / > method, not a reference, else you could have find out what classloader loaded > that class, and so find out the bundle. > > It's a nasty problem, but solution is more then welcome : All generic code > logging in one file isn't usefull without info what bundle used the generic > code. > > > > Igmar > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
