At 08:11 AM 10/17/2006, you wrote:
>Hi Jacob and all,
>I searched in the archives for the reason to wrapper the log and not
>just extend it. I found two reason:
>1. FQCN: the FQCN is defined in the Logger class so I could have some
>problems in the stacktrace handling when i want log also the source
>class/method of the call. I read this happens only for the class in the
>same package or something like that ...but i'm not able to find anymore
>the right thread in the archive. Do you have any notice ?
>2. problem with cast if my logger add/remove some methods.
>
> As mentioned by Ceky:
> However, sub-classing can be used to modify the behavior of
>existing Logger
> methods as long as no methods are added or removed, nor their
>signatures modified.
>
> and this is my case.
>
>Moreover I see a big drawback wrapping the logger because the users of
>my logger have to know the class of that and I prefer using keep this
>detail hidden (with the factory).
>Of course, I don't want to start a discussion about wrap and extend
>because this is amply discussed (when someone has to add a method the
>wrap is the right way) but i would like to be sure my approach is right
>in my case.
>
>What do you think ?
If you do it and understand what and why you are doing it, more power
to you. I think it's fine.
>
>About handling my case in a standard way, I image a interface
>LevelSelector and each Logger can have a level selector. Like for the
>appenders, log4j could provide some implementations as
>LoggerLevelSelector (this should return the level of the logger (maybe
>not needed)) or UserLevelSelector or MDCLevelSelector. ..
>
>Thanks a lot for your help.
I like the idea, though you do realize that this probably doesn't
have a chance of getting into either Log4j-1.2.xx or
Log4j-1.3. Log4j-2.0, however, is pretty wide open. I suggest you
fill out a Bugzilla feature request and provide a detailed
description of what you want there including implementation details,
if possible.
Jake
>
>ste
>
>
>Jacob Kjome wrote:
>
>> At 05:41 AM 10/15/2006, you wrote:
>> >Hi Jacob,
>> >thanks for your reply.
>> >
>> >Checking in the log4j source code, i saw all log methods and all guard
>> >methods performs something like this:
>> >
>> > public boolean isTraceEnabled() {
>> > if (repository.isDisabled(Level.TRACE_INT)) {
>> > return false;
>> > }
>> >
>> > return Level.TRACE.isGreaterOrEqual(this.getEffectiveLevel());
>> > }
>> >
>> >The repository level is set to ALL by default, so just overriding
>> >getEffectiveLevel() i'm able to have a per user level.
>> >
>> >I developed my Logger and my LoggerFactory. The LoggerFactory is needed
>> >just to create and return instances of my Logger.
>> >My Logger has just two methods:
>> >
>> > public
>> > Level getEffectiveLevel() {
>> > Level userLevel = getUserLevel((String)MDC.get("userName"));
>> > if (userLevel != null) {
>> > return userLevel;
>> > }
>> > for(Category c = this; c != null; c=c.getParent()) {
>> > if(c.getLevel() != null)
>> > return c.getLevel();
>> > }
>> > return null; // If reached will cause an NullPointerException.
>> > }
>> >
>> > private Level getUserLevel(String userName) {
>> > return _the_user_level;
>> > }
>> >
>> >
>> >This way seems to work fine, but does anyone see some
>> >issue/problem/drawback ?
>> >
>>
>> Other than the fact that you can't just plug the behavior in without
>> extension, it looks like a decent solution. And, normally, it is
>> recommended that Logger be wrapped than extended. Search the archives
>> for reasoning. But, if it works for you, that's great! I'd be
>> interested in being able to configure this in a standard way in the
>> long run.
>>
>> Jake
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
