At 15:22 29.01.2002 -0800, you wrote: >Sorry if I'm going off on a tangent here but our usage of >log4j does extend the category class for two reasons. > >First, we are extending the loggingEvent class so that the >message member can be serialized and to do that we needed >to override the forcedLog() method in category class.
Hello Peter, Why do you need to override the LoggingEvent class? The message object is available as is with the LoggingEvent.getMessage method. What could overriding the LoggingEvent class possibly bring you? >Second, we needed to extend the priority class because we >added 2 of our own and that needs the corresponding methods >to be added in category class also. This is a classical requirement. However, extending the Category class just for adding a few printing methods to support your new priorities is not a very good idea. Yes, JBoss does it. That is actually the cause of your problems: JBoss has its own subclass, you have your own subclass, and the two don't mix very well together. To support new printing methods for your custom priorities, you can use the general purpose Category.log(Priority, Objects) method. This is not as elegant as having new methods in your own category subclass but it is headache free. >I'm concerned with our extension by Ceki's reply that >extending the category class is a bad idea since we just >started using log4j and do not have much experience with >it. It would be much appreciated if Ceki could state some >of the issues we need to be aware of if we continue to use >our extension of the category class or if there is another >way to do what we need without having to extend the >category class. I hope I have answered your questions. -- Ceki Gülcü -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
