Peter, I'd like to pursue how I can adopt the framework for Avalon logging
to my needs.
My requirements are:
1. pluggable interface (framework gives this to me),
2. explicit declaration of the category name (i.e. class name), available
through the framework.
I understand that (2) violates the IoC, but if my only option is to appeal
to the implementation for the getRootLogger() method or the Hierarchy class
- then the framework doesn't meet my needs. Note that using your factory
below I can vary the HashMap key LoggerFactory.NAME to obtain any category
I want... how is this any different from what I've got below?
Regarding your factory, I prefer a more abstract factory, as below. It
requires code to initialize/construct the specific logger, but it doesn't
presume anything about the logger (config URL or other resources) - so I
believe it more directly addresses the flexibility required to obtain
access to unknown logger API implementations (and I'm trying to keep things
as simple as possible).
Thanks for your feedback.
<ras>
interface LogManager
{
public Logger getRootLogger(); // do we need this?
// You have already shown me how to implement getLogger() as
getRootLogger()getChild().
public Logger getLogger(java.lang.String name);
}
// A separate implementation of this interface should be defined
// for each current logging API: Log4J, LogKit, JSR47, etc.
//
// It may be that even more specific implementations of this
// factory are coded for applications with different requirements
// on logger initialization.
//
interface LogManagerFactory
{
// Create and initialize a LogManager.
//
public LogManager getLogManager();
}
class LogManagerHome
{
// Create a new LogManager for the given application.
//
// system property org.apache.common.logger specifies an
// implementation of the LogManagerFactory interface.
//
// This class creates and returns that logger.
//
static public LogManager getLogManager();
}
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability
WebSphere Development
IBM Software Group
Peter Donald
<[EMAIL PROTECTED] To: "Richard Sitze" <[EMAIL
PROTECTED]>, Berin
e.org> Loritsch <[EMAIL PROTECTED]>
cc: Russell Butek <[EMAIL
PROTECTED]>,
11/09/2001 [EMAIL PROTECTED], Greg Truty <[EMAIL
PROTECTED]>
02:56 AM Subject: Re: Common Logging
Interface
On Fri, 9 Nov 2001 08:45, Richard Sitze wrote:
> Berin/Peter: It looks like I'm following in your team's footsteps. I'd
> rather leverage your hard work and design then start a 6th API, or a
third
> variant of the Log4J/LogKit class interfaces. I had made assumptions
about
> LogKit, and I thank both of you, and Ceki, for your patience in educating
> me.
>
> Craig/Berin/Peter, has anyone considered moving the Avalon framework up
> into a jakarta common code package? Before the next release of Avalon
> commits to the logger frameword in it's current package?
>
> Berin, I retrieved the jakarta-avalon module from CVS, and I'm looking at
> the framework. I've got a few questions - and I'd be happy if you were
to
> answer them by pointing me to a document.
>
> 1. I must appeal to an implementation of the hierarchy to get a new
> category (independent of an existing logger). While I understand this
from
> the point of view of IoC, it doesn't mesh with the common practive of
using
> the fully qualified class name as the category id. Can you address this?
The category naming can still work fine with the Avalon method. We could
have
something like the following if the app wanted that sorta thing.
void setupLogger( LogEnabled logEnabled )
{
final String name = logEnabled.getClass().getName();
logEnabled.enableLogger( getLogger().getChildLogger( name ) );
}
Note that this assumes that getLogger() will return root logger.
The major difference is how they aquire the Logger. Those toolkits who do
Logger logger = MyToolkit.getLogger( "some.name" );
aren't really supported in the framework and IMO shouldn't be. This kinda
abstraction should definetly be left as an application specific service as
it
follows a very specific model (ie one JVM == 1 app) which is rarely
appropriate for serverside apps.
> 2. I think the answer to (1), in conjunction with the framework
approach,
> leads me to inquire about a factory for the logger implementation. I'm
> following down my original path, based on your framework. Are you
adverse
> to me introducing a factory in your framework if it's not hiding
somewhere
> already?
Heres something I wrote in earlier mail.
----------------
My proposal for an abstraction layer was originally the below LogFactory
and
the Logger interface in Avalon repository. The LoggerFactory would behave
like JNDi in that it could accept a map that has parameters. The default
values of map would be populated by a config file in the Classpath.
interface InitialLoggerFactory
{
Logger getLogger( Map map ) throws NoSuchLoggerException;
}
example usage.
Hashmap map = new HashMap();
map.put( LoggerFactory.NAME, "some-category-name" );
map.put( LoggerFactory.CONFIG_URL, "file:/some/config/file.txt" );
map.put( LoggerFactory.FACTORY_IMPL, "com.biz.LogKitLoggerFactory" );
InitialLoggerFactory factory = new InitialLoggerFactory();
Logger initialLogger = factory.getLogger( map );
another usage that just used defaults sucked in from entries in ClassLoader
would be
InitialLoggerFactory factory = new InitialLoggerFactory();
Logger initialLogger = factory.getLogger( new HashMap() );
--
Cheers,
Pete
--------------------------------------------------
Where ignorance is bliss, 'tis folly to be wise.
--------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
