- 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].

HTH

Jeff

[0] 
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/framework/bundles/org.eclipse.osgi/eclipseAdaptor/src/org/eclipse/core/runtime/internal/adaptor/ContextFinder.java?view=markup&root=RT_Project

On 2010-11-01, at 10:55 PM, Igmar Palsenberg wrote:

> Hi Neil,
> 
>> If bundle Y wants to know its immediate caller then it can call
>> Thread.currentThread.getStackTrace(). The problem is, this will not
>> tell you from which bundle you were called -- the only way to get that
>> kind of information is to register a ServiceFactory.
>> 
>> What is the purpose of bundle Y? It just seems to be getting in the
>> way. Why not call the LogService directly from bundle X?
> 
> Bundle Y is a utility bundle, of a library, dependent on how you define those 
> terms. Y doesn't do anything itself : It's just a big collection of useful 
> stuff.  X is a application that uses Y, so we want problems in Y to be put in 
> logfiles of bundle X, which is the caller. We now have no idea who called 
> services in Y, since problems can also be caused by something in X (bad call 
> sequence, runtime exception, etc).  
> 
> X is just one of it's kind : In the realworld, there a dozens of bundles on 
> the same level as X which all use services from bundle Y. In order to filter 
> messages in the appropriate logfiles of the X-level bundles, we need to know 
> the caller of services in bundle Y.
> 
> I hope the above makes things clear, and why we need to know the caller.
> 
> 
> 
> Regards,
> 
> 
>       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

Reply via email to