Re: Repository selectors, useful?
On 11/27/2008 12:56 PM, Ceki Gulcu wrote: > > > Thanks for your response. Comments inline. > > Jacob Kjome wrote: >> Hi Ceki, >> >> Can you please explain your change of heart first? I'll take a guess >> as to your >> skepticism... > >> 1. Very little built in support, making repository selectors >> generally a custom >> solution, which inhibits widespread use. This can be easily addressed. > > What do you mean by "very little built in support"? Do you mean in log4j > or in application containers. If the latter, then this cannot be easily > addressed. > Log4j 1.2.xx contains a RepositorySelector interface with no implementation and no well defined way of installing one. This was addressed in Log4j 1.3 (you must recall, no?)... but that died on the vine. Ideally application containers would support it but, like you say, that cannot be easily addressed. Ultimately, application containers don't have to provide any special support for it as long as logging implementations provide basic support for this themselves. So this is, indeed, "easily addressed" though maybe not "ideally addressed". >> 2. The use of static loggers as well as logger abstractions such as >> commons-logging and SLF4J (unless you use an implementation that >> directly extends >> SLF4J, such as Logback) break respository selectors anyway. > > True. > And it's a feature killer. Seems like there ought to be some way to address it? The repository selector is a great idea that needs to evolve into something less functionally fragile. >> 3. Even implementations that purport to support respository selectors >> fail to >> truly support them in practice as evidenced by the fact that Logback - >> having been >> in full release for a good while - is just now being fixed to properly >> support them. > > The problem was actually in SLF4J. > Hmmm... Except that you said "I am in the process of fixing bugs related to context selectors in logback." >> 4. A common deployment model these days is one app per/server. In >> this case, >> separating logging between applications is unnecessary because there >> is only one >> application. > > There are plenty of servers containing multiple applications. In such > cases, separation of logging can be accomplished by embedding a copy of > log4j.jar in the application itself. > This works very well in Tomcat standalone, no matter the global server classpath, because of child-first classloading. Other servers, not so much because they tend to use parent-first classloading. Some have the option to use child-first. However, in my experience, Tomcat is the only one that reliably supports child-first classloading. So, if Log4j is on the global container classpath, kiss per/application logging goodbye without the repository selector. Frankly, I'm surprised you would make this argument since it's one that's always been available since well before the concept of the repository selector. The fact that the repository selector concept even exists is evidence that the "simple" solution didn't fully meet the needs of per/application logging separation. Mind you, that's not to say that the repository selector concept finally met the need. No solution I've seen so far has been a panacea. >> That said, there's plenty of evidence, based on a quick search of the >> Log4j-user/dev mailing lists, that repository selectors are useful. >> In some >> cases, they are used to separate logging by some runtime attribute, >> such as IP >> address or thread, not just per/application (classloader or JNDI >> context). As >> such, choosing not to support the concept would disenfranchise a >> small, but >> nonetheless important, user base. > > I agree, although the same functionality can be addressed by simpler means. > And those "simpler means" are what exactly Jake - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository selectors, useful?
Thanks for your response. Comments inline. Jacob Kjome wrote: Hi Ceki, Can you please explain your change of heart first? I'll take a guess as to your skepticism... 1. Very little built in support, making repository selectors generally a custom solution, which inhibits widespread use. This can be easily addressed. What do you mean by "very little built in support"? Do you mean in log4j or in application containers. If the latter, then this cannot be easily addressed. 2. The use of static loggers as well as logger abstractions such as commons-logging and SLF4J (unless you use an implementation that directly extends SLF4J, such as Logback) break respository selectors anyway. True. 3. Even implementations that purport to support respository selectors fail to truly support them in practice as evidenced by the fact that Logback - having been in full release for a good while - is just now being fixed to properly support them. The problem was actually in SLF4J. 4. A common deployment model these days is one app per/server. In this case, separating logging between applications is unnecessary because there is only one application. There are plenty of servers containing multiple applications. In such cases, separation of logging can be accomplished by embedding a copy of log4j.jar in the application itself. That said, there's plenty of evidence, based on a quick search of the Log4j-user/dev mailing lists, that repository selectors are useful. In some cases, they are used to separate logging by some runtime attribute, such as IP address or thread, not just per/application (classloader or JNDI context). As such, choosing not to support the concept would disenfranchise a small, but nonetheless important, user base. I agree, although the same functionality can be addressed by simpler means. Jake -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: log4j ignoring log4j.properties and only showing INFO messages
Try using -Dlog4j.debug=true to see how Log4j is being configured. Maybe someone is performing manual configuration shortly after auto-configuration takes place? Jake On 11/26/2008 3:54 PM, Farrukh Najmi wrote: > I have been using log4j 1.2.14 and commons-logging 1.1 in my project > successfully for a long time. > All of a sudden I am finding that my log4j.properties file can no longer > control logging behavior > for log4j. The only messages that are logged are INFO messages. > > Since my project is a maven project with many direct and indirect > dependencies its possible that one of those dependencies changed in some way > to change my apps logging behavior. > > I have tried specifying my log4j file explicitly using system property: > > -Dlog4j.configuration=file:///somedir/log4j.properties > > No joy with that. Expected trace messages till did not appear. > > Then I wondered perhaps the problem is in commons-logging so I tried to turn > diagnostic on in common-logging using system property: > > -Dorg.apache.commons.logging.diagnostics.dest=somefile.txt > > Still no joy. No file was created. > > What could be wrong and how can I debug this further? > > Thanks for your help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Repository selectors, useful?
Hi Ceki, Can you please explain your change of heart first? I'll take a guess as to your skepticism... 1. Very little built in support, making repository selectors generally a custom solution, which inhibits widespread use. This can be easily addressed. 2. The use of static loggers as well as logger abstractions such as commons-logging and SLF4J (unless you use an implementation that directly extends SLF4J, such as Logback) break respository selectors anyway. 3. Even implementations that purport to support respository selectors fail to truly support them in practice as evidenced by the fact that Logback - having been in full release for a good while - is just now being fixed to properly support them. 4. A common deployment model these days is one app per/server. In this case, separating logging between applications is unnecessary because there is only one application. That said, there's plenty of evidence, based on a quick search of the Log4j-user/dev mailing lists, that repository selectors are useful. In some cases, they are used to separate logging by some runtime attribute, such as IP address or thread, not just per/application (classloader or JNDI context). As such, choosing not to support the concept would disenfranchise a small, but nonetheless important, user base. Jake On 12/26/2008 7:05 AM, Ceki Gulcu wrote: > > Hello, > > I am in the process of fixing bugs related to context selectors in logback. > Context selectors are the equivalent of repository selectors in log4j. > However, > while few years back I thought that context selectors, aka repository > selectors, > were the wave of the future, I am increasingly skeptical about their > usefulness. > > If you are using context/repository selectors, could you please explain > why? > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
rate control of logging events
Hello, I am using the SMTPAppender to send mails in case of errors. I have a requirement to have the number of error emails limited to e.g. 10 per minute. Is this possible with any of the standard filters? cheers, dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: [SPAM (Bayesain Analysis)] - Repository selectors, useful? - Bayesian Filter detected spam
Hello Bender, Thank you for your detailed response. I appreciate it. I believe that the problem you describe, namely separation of logging (per thread), can be accomplished by means other than repository selectors. Your requirements are duly noted. I intend to look into it and to offer a more convenient solution in the coming days. Cheers, Bender Heri wrote: > Hallo Ceki > > I found log4j's RepositorySelector very useful, I think I would not > have been able to solved my problem without it. > > I use it in a System which is designed to maintain different > customers. A single customer should never see any data (or even know > about the existence) of other customers. So I needed to separate also > all logs. One core application is a scheduler app which maintains > different jobs which run at regular intervals (configured for each > customer and job kind). The jobs make heavy use of common libraries > (in fact most of the work is done within these libraries, which make a > lot of log outputs). This log outputs should never mix between > customers and jobs. > > Such a job is running in its own thread. Therefore I can use the MDC > which is feeded at every thread start with infos about the current job > and the current customer. This info is then used by the repository > selector for choosing the correct repository (where file appenders are > defined with filenames and storage locations mirroring these MDC > infos). > > Maybe your new logback has other useful constructs to solve such a > problem. Using Log4j's RepositorySelector was a bit hard to understand > at the beginning, specially the need for having special logging code > (MDC, configuring the file appenders) at every thread start (was a bit > complex in combination with a thread pooling). I wished that such > things could be done only by configuration. More problems: Logger > instances in library classes cannot be instantiated statically, and > utility classes with static methods and other singletons must fetch > the logger on each method entry (I had to disable log outputs from > third party libraries which do not obey such circumstances). > > Greetings > Heri Bender > -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
