Hi Jin,
You are right to be concerned. Basically, the configurators don't know
about subclasses of Category by default. The following example illustrates
the problem. Let's say I have three categories with the following names:
"top", "top.x" and "top.y". Let's say you have the following lines in your
property file:
# define some appenders
# ...
log4j.category.top=INFO,appender1
log4j.category.top.x=DEBUG,appender2
Then in your code you do the following:
// Run property configurator
// ...
Category catx = AppServerCategory.getInstance("top.x");
Category caty = AppServerCategory.getInstance("top.y");
Running the configurator in the above code created two categories: "top"
and "top.x". Since the configurator does not know about subclasses, both
instances are of type Category. When the assignments are made to the
variables catx and caty, catx will have a Category instance because it was
created previously while caty will have an AppServerCategory instance and
work as desired.
I am usually not affected by this problem because the categories I
instanciate in my code are usually not the ones created by configurators.
They tend to by be like caty in the example above. In the cases where I
have an instance like catx, I must ensure that a creation is done before
the configuration.
It shouldn't have to be like this. Already the Property configurator lets
you determine the factory used but does not let you set attributes on the
factory. I hear you can also set the attributes though with the DOM
configurator.
You mentioned subclassing the PropertyConfigurator. That has some
interesting possibilities. The quick approach would be to merely override
the configureCategoryFactory method in a way that anticipates the kind of
properties the subclass provides. A longer approach would be to use
reflection for populating arbitrary attributes. Then anyone creating their
own subclass could use it.
The drawback to overriding configureCategoryFactory is that it is presently
only package accessible. You could just change this in your copy of the
code and recompile. Also, Ceki is usually open to increasing the exposure
of methods when there is a need.
Changing log4j as you need it before it becomes available generally is not
at all bad once you get use to it. It enables you to more tightly control
just what in the distribution changes. This is important in a distibuted
environment like the one in which I work. If the LoggingEvent class
changes at all (and it does), I will have to update all distributed servers
at once since they pass serialized logging events which fail to deserialize
if the versions are not compatible. Now that we are in production, I would
be hard pressed to do this unless it fixed a very serious problem.
Good luck,
- Paul
Paul Glezen
IT Specialist
WebSphere Engagement Team
Tel: 818 539 3321
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
