Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » Making static class members unique per bundle
Making static class members unique per bundle [message #51967] Mon, 31 October 2005 15:56 Go to next message
Jeremy Volkman is currently offline Jeremy VolkmanFriend
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 #51995 is a reply to message #51967] Mon, 31 October 2005 21:29 Go to previous messageGo to next message
venkataramana m is currently offline venkataramana mFriend
Messages: 86
Registered: July 2009
Member
May violate OSGi strong-points, how about sending a bundleId to some another API to get the logger...
just to make the things simpler, but a lil sacrifice on the maintenance.

class LogMgr 
{
	private static fDefault;
	private Hashtable fLoggers = new Hashtable();

	public static getDefault() 
	{
		if( fDefault == null )
			fDefault = new LogMgr();
	
		return fDefault;
	}
	
	public Log getLogger(String bundleId)
	{
		Log logger = fLoggers.get(bundleId);
		if( logger == null )
		{
			logger = LogFactory.getLog(..); /* i guess this creates */
			fLoggers.put(bundleId, logger);
		}

		return logger;	
	}

}


I dont think this will satisfy your requirements, but just incase somebody wants to do it this way ;-)

Thanks
Venkat
Re: Making static class members unique per bundle [message #52021 is a reply to message #51967] Tue, 01 November 2005 15:21 Go to previous messageGo to next message
Eclipse UserFriend
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
Re: Making static class members unique per bundle [message #52180 is a reply to message #52021] Wed, 02 November 2005 06:48 Go to previous message
Jeremy Volkman is currently offline Jeremy VolkmanFriend
Messages: 14
Registered: July 2009
Junior Member
Thanks for the tip! I've changed my implementation to use
PackageAdmin.getBundle(Class clazz). I still walk the call stack to find
calling classes, but I no longer have to register bundles at activation.
The reason I still walk the call stack is because I have a
logging-priority per bundle. For example, if a critical service bundle
executes a method in a library bundle, and that method logs a message, I'd
like that message to be logged under the critical service.
Previous Topic:SWORD4J Analyzed and Secured plugins in RCP platform
Next Topic:Concurrency Support
Goto Forum:
  


Current Time: Thu Apr 25 19:36:56 GMT 2024

Powered by FUDForum. Page generated in 0.02828 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top