Re: Log4j Dilemma (Was RE: [JBoss-dev] Tyrex...)
At 18:48 05.12.2002 -0600, Weiqi Gao wrote: Anatoly Akkerman wrote: Must be the Tyrex jar expects a different version of log4j than supplied by JBoss. You might need to adjust Tyrex sources and recompile it. Is this recommended approach for using third party software with JBoss? Adjust the sources and recompile? What if the source is not available? Apparently Tyrex is still using log4j 1.0. The change causing the problem is documented. From log4j's HISTORY file: February 23, 2001 - Release of version 1.1b1 - The FileAppender has been split into three parts: WriterAppender, ConsoleAppender and FileAppender. ConsoleAppender takes over the console logging functionality of FileAppender. As a result support for stream and console printing has been deprecated in FileAppender. [**] To correct the problem, it is sufficient to use WriterAppender instead of FileAppender. (It is a trivial change but that is easy for me to say.) -- Weiqi Gao [EMAIL PROTECTED] -- Ceki --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Deployers lifecycle/logging question
Scott, What does this mean? Log4j appenders will output events in the order it receives them. Do you have something else in mind? There is no guarentee of log message ordering in the standard log4j appenders. Scott Stark Chief Technology Officer JBoss Group, LLC -- Ceki --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Logging separation
Hi everyone, I have written a small specification for tacking the logging separation problem in servlet containers. It is available here: http://qos.ch/containers/sc.html Please do not hesitate to forward this email to forums where Container developers hang around. I've already forwarded it to tomcat-dev@ and jboss-dev@ mailing lists. Ietty, Resin, Orion, Websphere, Weblogic developers are also a target audience. If you are involved with these products I'd appreciate if you could inform the appropriate parties. Many thanks in advance, Ceki ps: My apologies for the noise. I assure you that it is exceptional. --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] JBoss and Apache
At 14:02 23.03.2002 -0800, marc fleury wrote: The interview states very clearly where I stand... Actually, your comments in the interview came though like an unwarranted attack against Jakarta whereas now your concern seems to be focused on the business model which is a very legitimate concern. The Apache Foundation model is incompatible with our professional vision. I view the ASF as a failure of the open source business model. I view Linux as an even bigger failure of the open source business model, so you see... :). Apache is rather big, Linux is even bigger. So characterizing Apache or Linux as one big flop is inaccurate. I don't think Apache is about financial success. We measure success by a different yardstick. I would even adventure to say that we don't really measure it. We want to grow the JBoss Group as an umbrella for all JBoss developers to offer professional services, it is already on. In Apache this is lost, it's not the model. Why do you think you couldn't pursue the same goals within Apache? What is there to prevent you? We are about promoting our way of life and I don't want to be employee of the month You can promote your way of life at Apache. The foundation takes great pride in not intervening in any project's internal affairs. That is how the foundation scales. Thanks for your time, -- Ceki My link of the month: http://java.sun.com/aboutJava/standardization/ ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Fwd: Re: The penny drops - JBoss Repository Selector
FYI I think jboss-dev is the most appropriate forum for this discussion. I will follow up with an answer to Adrian here. Regards, Ceki List-Id: Log4J Developers List log4j-dev.jakarta.apache.org Reply-To: Log4J Developers List [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] X-Originating-IP: [195.212.13.8] Reply-To: [EMAIL PROTECTED] From: Adrian Brock [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: The penny drops - JBoss Repository Selector Date: Thu, 17 Jan 2002 16:56:02 + X-OriginalArrivalTime: 17 Jan 2002 16:56:03.0039 (UTC) FILETIME=[D8CE06F0:01C19F77] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hi Ceki, I'm trying to reduce the length of my posts, this one will probably break that rule :-( Re: Repositories I'll try explaining this from the beginning. We basically agree but I'm not getting my point across about multiple repositories. Maybe I'm missing one of your points as well? :-) First, here is what JBoss does at the moment. Nearly the first thing that happens is to deploy an MBean called Log4JService. This has the task of locating the property file and sets up the configureAndWatch. So we have one hierarchy for all logging. The problem we are trying to solve is what happens when something doesn't like the JBoss configuration and tries to reconfigure log4j. A related issue (not the original problem raised on log4j-user) is that a user wants to take a component that already does logging and put it in its own hierarchy/configuration. There are two types of deployment within JBoss. 1) A service, such as embedded Tomcat. These could provide an internal mechanism for configuring log4j, it maybe useful for them to run in a different hierarchy. 2) An application. This is the original problem. The application wants to have a completely separate hierarchy and configuration to JBoss. The easy solution is every time I see a new ClassLoader in the RepositorySelector, create a new LoggerRepository. The configuration will either be specified at deployment or I use a fallback configuration. When something tries to reconfigure log4j it will be playing in its own backyard so problem solved. :-) But there are 50+ services in the default configuration of JBoss. Probably only the Web Server may want to reconfigure. The rest just want to use the JBoss hierarchy and configuration. I would like to let them share the same repository rather than creating 50 watchdog threads. Now the extra complication I introduced. The deployer may want all their applications running in the repository/hierarchy, but not the JBoss one. Again it would be wasteful to create a repository for each application when they are all sharing. I am not saying this is what will happen. As you said each applcation may want to specify its own log4j.properties. In this case, they each get a repository. Am I on the right track, have I over complicated this? Maybe I'm concentrating too much on the 5% instead of the 95%? I'll pickup the how to specify the url/configurator problem once I've nailed the RepositorySelector. I know what the configuration is, it's just where to put it. JBoss.xml is one idea but that don't exist for for pure web-apps :-( Unrelated point: I spotted this in log4j-1.2alpha6 javadocs org.apache.log4j.varia.PriorityMatchFilter is deprecated to itself, recursive deprecation :-) Regards, Adrian ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
The problem *I* am interested in solving is to let each application have in its own independent logging universe. I don't see a problem with JBoss components sharing one logging universe (that of JBoss). The case of Tomcat or any other servlet container is very interesting because the user's servlet code is part of the user's application. Consequently, servlets should log on the logging universe of larger application. With the Weblogic 6.1 classloading scheme, this is very easy to accomplish. In the Weblogic 6.1 classloader hierarchy EJBs have a classloader which is also the parent of the web-application (WAR) classloader. Thus, servlet code naturally log using the log4j classes loaded by the EJB classloader. In other words, one logging universe for the whole application. I am not familiar with JBoss way of organizing the classloader hierarchy although I would like to learn. Anyway, some entity has to know at some point in time which WAR is associated with which (EJB) JAR. That entity can easily set the oops... Jboss embeds the whole of Tomcat/Jetter/whatever. OK then how can the servlets in an application access the *local* interface of entity beans? Do you know what I am talking about? Has this issue been addressed in JBoss 3.0? Regards, Ceki At 16:56 17.01.2002 +, Adrian Brock [EMAIL PROTECTED] wrote: Hi Ceki, I'm trying to reduce the length of my posts, this one will probably break that rule :-( Re: Repositories I'll try explaining this from the beginning. We basically agree but I'm not getting my point across about multiple repositories. Maybe I'm missing one of your points as well? :-) First, here is what JBoss does at the moment. Nearly the first thing that happens is to deploy an MBean called Log4JService. This has the task of locating the property file and sets up the configureAndWatch. So we have one hierarchy for all logging. The problem we are trying to solve is what happens when something doesn't like the JBoss configuration and tries to reconfigure log4j. A related issue (not the original problem raised on log4j-user) is that a user wants to take a component that already does logging and put it in its own hierarchy/configuration. There are two types of deployment within JBoss. 1) A service, such as embedded Tomcat. These could provide an internal mechanism for configuring log4j, it maybe useful for them to run in a different hierarchy. 2) An application. This is the original problem. The application wants to have a completely separate hierarchy and configuration to JBoss. The easy solution is every time I see a new ClassLoader in the RepositorySelector, create a new LoggerRepository. The configuration will either be specified at deployment or I use a fallback configuration. When something tries to reconfigure log4j it will be playing in its own backyard so problem solved. :-) But there are 50+ services in the default configuration of JBoss. Probably only the Web Server may want to reconfigure. The rest just want to use the JBoss hierarchy and configuration. I would like to let them share the same repository rather than creating 50 watchdog threads. Now the extra complication I introduced. The deployer may want all their applications running in the repository/hierarchy, but not the JBoss one. Again it would be wasteful to create a repository for each application when they are all sharing. I am not saying this is what will happen. As you said each applcation may want to specify its own log4j.properties. In this case, they each get a repository. ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
RE: [JBoss-dev] Re: The penny drops - JBoss Repository Selector
want to reconfigure. The rest just |want to use the JBoss hierarchy and configuration. I would like |to let them share the same repository rather than creating 50 |watchdog threads. | |Now the extra complication I introduced. |The deployer may want all their applications running in the |repository/hierarchy, but not the JBoss one. |Again it would be wasteful to create a repository for each |application when they are all sharing. |I am not saying this is what will happen. As you said each applcation |may want to specify its own log4j.properties. In this case, they |each get a repository. -- Ceki Gülcü - http://qos.ch ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] Re: The penny drops - JBoss Repository Selector
Hi Adrian, At 14:04 16.01.2002 +, Adrian Brock wrote: Hi Ceki, Firstly, sorry for posting to log4j-user instead of jboss-user I spotted my mistake just as I hit send :-( Re: WeakHashMap It doesn't make any difference if I do an explicit remove, it will remain on the heap until the garbage collector figures out it is unused. It might speed up the get(), but lots of deploy/undeploy is not a normal operation - optimization isn't very important here. I'll probably do it because I could hit problems with cross linking between classes loaded in the repositories from the classloaders used in the keys. I'm might not use repositories directly, see later. Re: Configuration I'm pretty happy with the mechanics. The spi.Configurator makes this very flexible, your example code has the idea. My problems are the following: 1) Unnecessary multiplication of Repostiories/Configuration Now I know this can be done per ClassLoader, this opens up the ability to do this for every JBoss component, in particular the embedded webserver (Tomcat). This may want to perform the configuration itself, which is fine, but it is more likely it will be configured through a JBoss mechanism see point 2. What I don't want to do is create 50+ repositories all doing configure and watch on the same url, just because the webserver *might* want use a different one. 50+? Isn't that rather unlikely? Moreover, who says they will watch the same URL? I think the best approach is to add an extra level of indirection. One map does ClassLoader-ConfigURL, then a second does ConfigURL-Repository. Does this sound ok, one repository is created per config url. I might need to cater for per URL/LoggingCongifurator if somebody wants to be stupid. How do you intend to deal with relative config files? For example, the user might specify log4j.properties as resource within the J2EE application. Sticking to one LoggerRepository per J2EE application is a simple and safe policy. You might be painting yourself into a corner imho. 2) Deployment Configuration This isn't a log4j issue at all. Right, it isn't. In your example code you have app.getLoggingConfigurationApplicationResourceURL() it's the mechanics of this I haven't figured out. The config information would be application specific and would probably go into jboss-???.xml, a file shipped with the ear file. Do you want me to go into this here? Do you want to *move* this discussion to jboss-development? I copied jboss-development just to do just that... For those on jboss-dev who did not follow the beginning of this discussion on log4j-dev, here are the relevant threads: http://marc.theaimsgroup.com/?t=10107551141r=1w=2 http://marc.theaimsgroup.com/?t=10111351264r=1w=2 Regards, Ceki ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [PATCH] Log4j 1.2alpha compatibility upgrade
Hello,
The included patches allow Jboss (latest CVS-snapshot) to work with log4j 1.2alpa1,
xdoclet-related patches are also included. You can continue to use your own subclass
of Category although this is likely to cause problems if and when you decide to
support the LogManager architecture.
Let me know if you need further clarifications. Regards,
ps: JBoss is pretty awesome. Well done!
--
Ceki Gülcü - http://qos.ch
Index: server/src/main/org/jboss/logging/TracePriority.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/TracePriority.java,v
retrieving revision 1.1
diff -u -r1.1 TracePriority.java
--- server/src/main/org/jboss/logging/TracePriority.java2001/09/11 18:35:02
1.1
+++ server/src/main/org/jboss/logging/TracePriority.java2001/10/01 08:12:49
@@ -6,7 +6,7 @@
*/
package org.jboss.logging;
-import org.apache.log4j.Priority;
+import org.apache.log4j.Level;
/** Adds a trace priority that is below the standard log4j DEBUG priority.
This is a custom priority that is 100 below the Priority.DEBUG_INT and
@@ -19,11 +19,11 @@
@author [EMAIL PROTECTED]
@version $Revision: 1.1 $
*/
-public class TracePriority extends Priority
+public class TracePriority extends Level
{
// Constants -
/** The integer representation of the priority, (Priority.DEBUG_INT - 100) */
- public static final int TRACE_INT = Priority.DEBUG_INT - 100;
+ public static final int TRACE_INT = Level.DEBUG_INT - 100;
/** The TRACE priority object singleton */
public static final TracePriority TRACE = new TracePriority(TRACE_INT, TRACE);
@@ -34,27 +34,27 @@
fails, then this method returns the specified default.
@return the Priority object for name if one exists, defaultPriority otherwize.
*/
- public static Priority toPriority(String name, Priority defaultPriority)
+ public static Level toLevel(String name, Level defaultLevel)
{
if( name == null )
return TRACE;
- Priority p = TRACE;
+ Level p = TRACE;
if( name.charAt(0) != 'T' )
- p = Priority.toPriority(name, defaultPriority);
+ p = Level.toLevel(name, defaultLevel);
return p;
}
/** Convert an integer passed as argument to a priority. If the conversion
fails, then this method returns the specified default.
@return the Priority object for i if one exists, defaultPriority otherwize.
*/
- public static Priority toPriority(int i, Priority defaultPriority)
+ public static Level toLevel(int i, Level defaultLevel)
{
- Priority p;
+ Level p;
if( i == TRACE_INT )
p = TRACE;
else
- p = Priority.toPriority(i);
+ p = Level.toLevel(i);
return p;
}
Index: DocletUtil.java
===
RCS file: /cvsroot/xdoclet/xdoclet/core/src/xdoclet/util/DocletUtil.java,v
retrieving revision 1.5
diff -u -r1.5 DocletUtil.java
--- DocletUtil.java 2001/09/04 14:46:27 1.5
+++ DocletUtil.java 2001/10/01 06:47:44
@@ -5,6 +5,7 @@
import java.util.*;
import com.sun.javadoc.*;
import org.apache.log4j.Category;
+import org.apache.log4j.Logger;
/**
* @author Ara Abrahamian ([EMAIL PROTECTED])
@@ -186,9 +187,9 @@
* @param name Description of Parameter
* @returnThe Category value
*/
- protected static Category getCategory( Class clazz, String name )
+ protected static Logger getCategory( Class clazz, String name )
{
- Category cat = Category.getInstance( clazz.getName() + . + name );
+ Logger cat = Logger.getLogger( clazz.getName() + . + name );
return cat;
}
Index: server/src/main/org/jboss/logging/Logger.java
===
RCS file: /cvsroot/jboss/jboss/src/main/org/jboss/logging/Logger.java,v
retrieving revision 1.13
diff -u -r1.13 Logger.java
--- server/src/main/org/jboss/logging/Logger.java 2001/09/11 18:35:02 1.13
+++ server/src/main/org/jboss/logging/Logger.java 2001/10/01 08:16:03
@@ -6,8 +6,9 @@
*/
package org.jboss.logging;
-import org.apache.log4j.Category;
-import org.apache.log4j.spi.CategoryFactory;
+//import org.apache.log4j.Logger;
+//import org.apache.log4j.spi.LoggerFactory;
+import org.apache.log4j.LogManager;
/** A custom log4j Category subclass that add a trace level priority.
* @see #isTraceEnabled
@@ -17,29 +18,29 @@
* @author [EMAIL PROTECTED]
* @version $Revision: 1.13 $
*/
-public class Logger extends Category
+public class Logger extends org.apache.log4j.Logger
{
// Constants -
// Attributes
- private static CategoryFactory factory = new
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
