Making static class members unique per bundle [message #51967] |
Mon, 31 October 2005 15:56 |
Jeremy Volkman Messages: 14 Registered: July 2009 |
Junior Member |
|
|
I am using several components which utilize Apache's Jakarta Commons
Logging API to log messages. I would like to log messages on a per-bundle
basis. This is easy in OSGi land, using a ServiceFactory. However, a
standard use of the JCL API is:
protected final Log logger = LogFactory.getLog(getClass());
The problem here is that LogFactory.getLog(), a static method, has no way
of knowing which bundle is requesting a Log object. One way around this
(I believe) is to have each bundle include its own copy of the LogFactory
class instead of sharing the class from one library. This however can
become a maintenance nightmare, and negates one of OSGi's strong points.
It would be nice if a bundle could have its own unique "instance" of the
static LogFactory class. Therefore, any class requesting the static
LogFactory.getLog() method would get the instance associated with the
ClassLoader's corresponding bundle.
Is this at all possible (possibly with a few modifications/extensions to
the Framework)?
My current solution to the issue is to have Bundles register their
ClassLoader with a modified LogFactory class upon bundle activation.
LogFactory.getLog() then analyzes the call stack (provided by
SecurityManager.getClassContext()) to see if one of the Class objects in
the call stack belongs to a registered ClassLoader. This, of course, is
not the optimal solution to the problem, but it works for now.
Thanks,
Jeremy Volkman
|
|
|
|
Re: Making static class members unique per bundle [message #52021 is a reply to message #51967] |
Tue, 01 November 2005 15:21 |
Eclipse User |
|
|
|
Originally posted by: skaegi.sympatico.ca
For your example
protected final Log logger = LogFactory.getLog(getClass());
An alternate to your solution of registering a ClassLoader and walking the
stack might be to write a LogFactory that uses the PackageAdmin service's
[Bundle getBundle(Class clazz)] method. With a little work this would give
you your per bundle Logger (or set of Loggers associated with a bundle).
On the plus side Bundles using the LogFactory no longer need to do
registration work in their BundleActivator.
On the minus side the bundle offering the new LogFactory would now require
AdminPermission.
-Simon
|
|
|
|
Powered by
FUDForum. Page generated in 0.02621 seconds