You should wrap, not subclass, Logger. See the recent discussion on
this topic. I responded to that one and it applies here as well.
Jake
At 02:34 PM 4/21/2006, you wrote:
>I'm using a project that rolled yet-another-special logger. It looks
>like Log4j (mimics the API) and uses Log4j under covers; just the
>MyLogger class is not a Logger subclass.
>
>I'd like to correct this by subclassing MyLogger from Logger. However,
>all the code in my application uses
> MyLogger.getInstance(String);
>to instantiate the logger. If I make MyLogger a Logger subclass, I get
>a compilation error because it conflicts with a
> public static Category getInstance(String name)
>in the Category class. Since Category is "kind of" deprecated (not
>marked so but discouraged), I think there would be little harm in
>removing the two getInstance() methods from Category in a subsequent
>release (I looked and both 1.2.x and 1.3.x use these two methods).
>
>Please note I know how to create and use a Logger subclass (as shown
>in examples/subclass in the distribution). I know that the proper way
>to get a custom logger is to use:
> MyLogger c = (MyLogger) MyLogger.getLogger("some.cat");
>but I have a large legacy application that uses getInstance() all over
>and I can't replace all the calls.
>
>I know that removing the methods would break the (ancient) code that
>still uses Category. I just figured that after 4 years of deprecated
>warnings, it would be OK to yank it from new release.
>
>Thank you for considering this request,
>Peter
>
>
>---------------------------------------------------------------------
>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]
