RE: [JBoss-dev] jboss and log4j version 1.2
Hello Jason, There is no firm release date for 1.2. It will be released when it is ready. However, 1.2alpha0 is available since yesterday. :-) Extending the interface of Logger (i.e. Category) with new printing methods such as trace() is considered bad practice, at least by me. I understand that adding printing methods is consistent with the rest of the API, easy on the fingers and eyes. That is not good enough a reason. Log4j can never guarantee that a given category will be of a certain type, say org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger. ClassCastException when instantiating a Category subclass is one example of this problem. See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce In the future, I expect that Application Servers or Servlet Containers will impose a particular org.apache.log4j.Logger implementation (for security reasons). It will not be up to an embedded component to decide the logger subclass. Thus, you will not be able to rely on a org.jboss.logging.log4j.JBossCategory being returned even if you set the categoryFactory to org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the configuration file. Log4j support in JBoss is particularly important. I suggest that you look into the LogManager, RepositorySelector and LoggerRepository code. See also http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718 The whole construction is intended to allow Application Servers to select the appropriate LoggerRepository depending on the embedded application. Let me give an example. Assume we have to applications App-A and App-B running inside JBoss. We want App-A and App-B to live in separate logging universes. We achieve this by having App-A and App-B use different LoggerRepositories (LoggerRepository is the new name for Hierarchies in log4j 1.2). Clients still call Logger.getLogger(name) to retrieve a logger (= category). However, we want to vary the LoggerRepository (~hierarchy) depending on the caller. For a call to Logger.getLogger(name) emanating from code in App-A, we want JBoss to detect that the caller is in App-A and use the LoggerRepository specific to App-A. Similarly, calling Logger.getLogger(name) within App-B should use a LoggerRepository specific to App-B. Since JBoss is the top-level application, JBoss is free to impose the RepositorySelector to the LogManager. JBoss' implementation of RepositorySelector can use different methods to track the caller (the particular application), for example by setting a ThreadLocal variable to track applications by Thread. Regarding your last question, the DOMConfigurator offers more services than ProppertyConfigurator and is considered as stable. Don't hesitate to contact me if you encounter problems when migrating to the DOMConfigurator. Regards, Ceki Gülcü -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 11:10 PM To: '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] jboss and log4j version 1.2 Hello, Hi. There are a few changes in log4j 1.2 that require your attention. Any clues to when 1.2 will be released? I also strongly recommend against sub-classing Logger (or Category) to introduce new printing methods, you can use the general purpose log method instead. For example, for some category-subclass object x instead of writing x.trace(hello) you can write x.log(SomePrioritySubclass.TRACE, hello); Why? The first is consistent with the other logging methods and it is terse (easy on the eyes and fingers). If I am not mistaken, JBoss also uses deprecated and now removed methods such as getOptions/setOptions in its own appenders. There is no need for this as log4j uses introspection to configure its appenders and layouts. I don't know anything about these, but we should fix that. Please let me know if you have any questions or comments. Regards, Ceki Thanks for the update. Do you know if the xml config bits support all of the features that the property based config does? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
Hate to follow up on myself but my previous discussion is based on the premise that log4j classes are loaded once and for all for everyone at JBoss startup time. Playing class loader tricks à la Tomcat-Catalina makes it a totally different game. Am I correct to assume that log4j classes are loaded once and for all by Jboss? Regards, Ceki -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED]] Sent: Wednesday, September 26, 2001 10:07 AM To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-dev] jboss and log4j version 1.2 Hello Jason, There is no firm release date for 1.2. It will be released when it is ready. However, 1.2alpha0 is available since yesterday. :-) Extending the interface of Logger (i.e. Category) with new printing methods such as trace() is considered bad practice, at least by me. I understand that adding printing methods is consistent with the rest of the API, easy on the fingers and eyes. That is not good enough a reason. Log4j can never guarantee that a given category will be of a certain type, say org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger. ClassCastException when instantiating a Category subclass is one example of this problem. See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce In the future, I expect that Application Servers or Servlet Containers will impose a particular org.apache.log4j.Logger implementation (for security reasons). It will not be up to an embedded component to decide the logger subclass. Thus, you will not be able to rely on a org.jboss.logging.log4j.JBossCategory being returned even if you set the categoryFactory to org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the configuration file. Log4j support in JBoss is particularly important. I suggest that you look into the LogManager, RepositorySelector and LoggerRepository code. See also http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718 The whole construction is intended to allow Application Servers to select the appropriate LoggerRepository depending on the embedded application. Let me give an example. Assume we have to applications App-A and App-B running inside JBoss. We want App-A and App-B to live in separate logging universes. We achieve this by having App-A and App-B use different LoggerRepositories (LoggerRepository is the new name for Hierarchies in log4j 1.2). Clients still call Logger.getLogger(name) to retrieve a logger (= category). However, we want to vary the LoggerRepository (~hierarchy) depending on the caller. For a call to Logger.getLogger(name) emanating from code in App-A, we want JBoss to detect that the caller is in App-A and use the LoggerRepository specific to App-A. Similarly, calling Logger.getLogger(name) within App-B should use a LoggerRepository specific to App-B. Since JBoss is the top-level application, JBoss is free to impose the RepositorySelector to the LogManager. JBoss' implementation of RepositorySelector can use different methods to track the caller (the particular application), for example by setting a ThreadLocal variable to track applications by Thread. Regarding your last question, the DOMConfigurator offers more services than ProppertyConfigurator and is considered as stable. Don't hesitate to contact me if you encounter problems when migrating to the DOMConfigurator. Regards, Ceki Gülcü -Original Message- From: Jason Dillon [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 25, 2001 11:10 PM To: '[EMAIL PROTECTED]' Subject: Re: [JBoss-dev] jboss and log4j version 1.2 Hello, Hi. There are a few changes in log4j 1.2 that require your attention. Any clues to when 1.2 will be released? I also strongly recommend against sub-classing Logger (or Category) to introduce new printing methods, you can use the general purpose log method instead. For example, for some category-subclass object x instead of writing x.trace(hello) you can write x.log(SomePrioritySubclass.TRACE, hello); Why? The first is consistent with the other logging methods and it is terse (easy on the eyes and fingers). If I am not mistaken, JBoss also uses deprecated and now removed methods such as getOptions/setOptions in its own appenders. There is no need for this as log4j uses introspection to configure its appenders and layouts. I don't know anything about these, but we should fix that. Please let me know if you have any questions or comments. Regards, Ceki Thanks for the update. Do you know if the xml config bits support all of the features that the property based config does? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development ___ Jboss-development
Re: [JBoss-dev] jboss and log4j version 1.2
That is the case. - Original Message - From: Ceki Gülcü [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 26, 2001 1:13 AM Subject: RE: [JBoss-dev] jboss and log4j version 1.2 Hate to follow up on myself but my previous discussion is based on the premise that log4j classes are loaded once and for all for everyone at JBoss startup time. Playing class loader tricks à la Tomcat-Catalina makes it a totally different game. Am I correct to assume that log4j classes are loaded once and for all by Jboss? Regards, Ceki ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
Hello Jason, There is no firm release date for 1.2. It will be released when it is ready. However, 1.2alpha0 is available since yesterday. :-) Is there any compelling reason why we should switch to this alpha? I am all for the new API, but I am very weary of alpha/beta product. Extending the interface of Logger (i.e. Category) with new printing methods such as trace() is considered bad practice, at least by me. I understand that adding printing methods is consistent with the rest of the API, easy on the fingers and eyes. That is not good enough a reason. Log4j can never guarantee that a given category will be of a certain type, say org.jboss.logging.log4j.JBossCategory instead of org.apache.log4j.Logger. ClassCastException when instantiating a Category subclass is one example of this problem. See also http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce I see your point here, but the suggested usage for implementing trace() is just plain ugly. I would still suggest that we use our own Logger class which has all of the features and niceness which we desire, but uses Log4j as the underlying mechanism. I have been playing with logging systems for several years now, and I am coming to the conclusion that there is no single perfect logging api for application use. I am starting to think that each platform (like JBoss) should provide it's own interface, but leave the details of event management, configuration and the like, to a package like Log4j. I have not looked into the new LogManager and related classes yet, but I am glad to see things moving in this direction. I can totally see that I might want to completly disable logging via a NullLogger for some components, where I might want full thread dumps from others. Having one class handle both of these extremes will slow things down. Anyways, I would suggest that JBoss alter Logger to extend Object and make it a thin proxy to a Log4j logger. This way we don't have to worry about any class cast issues, and we can have a trace(), plus other features. In the future, I expect that Application Servers or Servlet Containers will impose a particular org.apache.log4j.Logger implementation (for security reasons). It will not be up to an embedded component to decide the logger subclass. Thus, you will not be able to rely on a org.jboss.logging.log4j.JBossCategory being returned even if you set the categoryFactory to org.jboss.logging.log4j.JBossCategory$JBossCategoryFactory in the configuration file. As I mentioned before, I would still expect our core components and plugins to use the JBoss Logger.create() methods to get an instance of a Logger. Log4j support in JBoss is particularly important. I suggest that you look into the LogManager, RepositorySelector and LoggerRepository code. See also http://jakarta.apache.org/log4j/docs/manual/manual.html#AEN718 Logging in an application server and the applications which run in it is very, very important. I have been playing with my own Bliss planet57.log api for a while now, but have finally concieded the backed to Log4j, since you do it much better than I could hope to given the time I have to work on it. The whole construction is intended to allow Application Servers to select the appropriate LoggerRepository depending on the embedded application. Let me give an example. Assume we have to applications App-A and App-B running inside JBoss. We want App-A and App-B to live in separate logging universes. We achieve this by having App-A and App-B use different LoggerRepositories (LoggerRepository is the new name for Hierarchies in log4j 1.2). Clients still call Logger.getLogger(name) to retrieve a logger (= category). However, we want to vary the LoggerRepository (~hierarchy) depending on the caller. For a call to Logger.getLogger(name) emanating from code in App-A, we want JBoss to detect that the caller is in App-A and use the LoggerRepository specific to App-A. Similarly, calling Logger.getLogger(name) within App-B should use a LoggerRepository specific to App-B. Sounds very, very interesting. I will have to look into this more. Since JBoss is the top-level application, JBoss is free to impose the RepositorySelector to the LogManager. JBoss' implementation of RepositorySelector can use different methods to track the caller (the particular application), for example by setting a ThreadLocal variable to track applications by Thread. Regarding your last question, the DOMConfigurator offers more services than ProppertyConfigurator and is considered as stable. Don't hesitate to contact me if you encounter problems when migrating to the DOMConfigurator. Thanks, --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] jboss and log4j version 1.2
I see your point here, but the suggested usage for implementing trace() is just plain ugly. I would still suggest that we use our own Logger class which has all of the features and niceness which we desire, but uses Log4j as the underlying mechanism. I have been playing with logging systems for several years now, and I am coming to the conclusion that there is no single perfect logging api for application use. I am starting to think that each platform (like JBoss) should provide it's own interface, but leave the details of event management, configuration and the like, to a package like Log4j. I used to be of the same opinion, but think that when you have logging disabled you want it as fast as possible (AFAIK it involves keeping as little inheritance as possible and so on). Unless you keep programming in the isDebugEnabled() way or implement it again in that thin layer, you'll get a bit slower system (remember that the log is called hundreds of times). You can also wait until the API JSR047 that Sun is developing matures and see what it's like: http://jcp.org/aboutJava/communityprocess/review/jsr047/index.html P.S.: The isDebugEnabled way as far as I remember from memory, involves checking the debugging state before calling the log method, to avoid calculating the parameters when there is no need: if (isDebugEnabled()) log.debug(Parameters = + param1 + , + param2); ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] jboss and log4j version 1.2
Hello, Hi. There are a few changes in log4j 1.2 that require your attention. Any clues to when 1.2 will be released? I also strongly recommend against sub-classing Logger (or Category) to introduce new printing methods, you can use the general purpose log method instead. For example, for some category-subclass object x instead of writing x.trace(hello) you can write x.log(SomePrioritySubclass.TRACE, hello); Why? The first is consistent with the other logging methods and it is terse (easy on the eyes and fingers). If I am not mistaken, JBoss also uses deprecated and now removed methods such as getOptions/setOptions in its own appenders. There is no need for this as log4j uses introspection to configure its appenders and layouts. I don't know anything about these, but we should fix that. Please let me know if you have any questions or comments. Regards, Ceki Thanks for the update. Do you know if the xml config bits support all of the features that the property based config does? --jason ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
