Log4j SocketServer
Hi, I have the following question regarding the class SocketServer.java (used to allow TCP connection): In the function main, when a connection is accepted a thread is created at the following line: new Thread(new SocketNode(socket, h)).start(); As the reference to this thread is not kept any where in the program then this thread will be in the list of items to be cleaned by the garbage collector. Thus, when the socket node and the thread are both cleaned by GC then the TCP appender will have to reconnect again. My question is: Are the log4j TCP server and appender using one socket for several logging events (until the TCP appender is closed) or is the TCP server creating a socket node for every one or two logging events (depending on socket status (deleted or not)).? Thanks El-Yamine Kettal This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: creating log file for each user
Do you have any clustering Issues with your MDB's? --- In [EMAIL PROTECTED], Ebersole, Steven [EMAIL PROTECTED] wrote: I do this exact same thing through JMS logging. I have a User object which acquires a per-instance Logger by doing : Logger.getLogger ( session. + getUserName() ). In my config I then have an explicit entry for session which pushes out to the appropriate JMS destination. There is then a message-driven EJB listening on that destination which decodes the username from the LoggingEvent and pushes to the appropriate file. Of course, as you mention that is pretty coding intensive (relative to some config file driven solution). The other options I thought of were as foloows: 1) Add explicit entries into your config file for each and every user. Of course this requires that you know in advance all the users of your system. Of course you could add in logic to the UseCase of adding a user to the system to generate a new entry into the log4j config file, but that in-and-of-itself is pretty code intensive. 2) If your users are stored in LDAP or a database or some other easily accessible format, you can try a manual configuration of log4j for these users in a startup class. This would basically be defining loggers, appenders, etc on the fly. 3) A custom appender subclassing FileAppender which knows how to discriminate the final target file based on the category name of the event. The file defined in the config would be a base directory and the appender would simply manage output to seperate files in that directory. Just some more ideas. HTH Steve Ebersole IT Integration Engineer Vignette Corporation 512.741.4195 Visit http://www.vignette.com -Original Message- From: Saif Khaja [mailto:ksaif25@h...] Sent: Monday, July 01, 2002 1:51 PM To: [EMAIL PROTECTED] Subject: creating log file for each user We have our application running on Websphere with log4j 1.1.3. It involves some complicated calculations for each transaction that user performs. Every thing goes on fine except that since there is just one common log file, these calculations log statments get intermingled among different users making it hard to debug an issue. What I was trying to achieve is a way to create a log file for each user. This way, all complex calculations log statements will be separate for each user making it easier to debug if we have to. I did spend quite a while going thru the archives on this issue but couldnt find one. So if this has been discussed already, I apologize for it. Among the existing appenders/patterns in log4j, I could use the following to achieve the same thing: 1. jdbcappender: send the log statements to the database and can query them on each user. This would however take too much database space. 2. jmsappender: I havent really looked closely at this one yet. But I know I could receive the log statements and write some custom code to put each log statement in a separate file based on the user who initiated it. 3. xmllayout: Generate xml version of the log file and write xsl to display the log file for requested user. I was wondering if there is a quicker/cleaner way or am I just complicating things for myself to achieve this. And if there is none, is there something that is planned in near future. Thanks, Saif. _ Send and receive Hotmail on your mobile device: http://mobile.msn.com -- To unsubscribe, e-mail: mailto:log4j-user-unsubscribe@j... For additional commands, e-mail: mailto:log4j-user-help@j... -- To unsubscribe, e-mail: mailto:log4j-user-unsubscribe@j... For additional commands, e-mail: mailto:log4j-user-help@j... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problem configuring Log4j for Weblogic 6.1
Just works fine. Awesome..
thanks
sudhi
--- Ceki Gülcü [EMAIL PROTECTED] wrote:
The warning message says otherwise.
At 08:25 26.08.2002 -0700, you wrote:
I am loading this property file before doing
anything
else. This is the first thing being loaded.
thanks
sudhi
--- Ceki Gülcü [EMAIL PROTECTED] wrote:
It looks that log4j is configured using your
configuration file. However,
you or some other code is attempting to use
log4j
prior to its
configuration, hence the warning message.
At 07:20 26.08.2002 -0700, you wrote:
Hi All,
I am having problems configuring log4j with
Weblogic
6.1.
I have the configuration for log4j as follows
in a
file called generic properties which get loaded
by
a
startup class
# log4j configuration
log4j.debug=true
#log4j.disable=fatal
log4j.additivity.epeople=true
log4j.rootCategory=DEBUG,stdout, R
log4j.appender.R=org.apache.log4j.RollingFileAppender
log4j.appender.R.File=c:/bea/wlserver6.1/config/sudhendras/logger.log
log4j.appender.R.MaxFileSize=100KB
log4j.appender.R.MaxBackupIndex=1
log4j.appender.R.layout=org.apache.log4j.PatternLayout
log4j.appender.R.layout.ConversionPattern=%d
%-5p
%c{1} %M - %m%n
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.logger.epeople=DEBUG
These properties gets loaded as a properties in
startup class as follows.
import java.io.*;
import java.util.Properties;
import org.apache.log4j.xml.DOMConfigurator;
import org.apache.log4j.*;
import weblogic.common.*;
import com.epeople.config.*;
/**
* Insert the type's description here.
* Creation date: (12/5/00 11:12:13 AM)
* @author: Administrator
*/
public class ApacheLoggerStartUp implements
weblogic.common.T3StartupDef {
/**
* ApacheLoggerStartUp constructor
comment.
*/
private static final String
m_logConfigurationFile
=c:\\ep\\properties\\log4j.properties;
public ApacheLoggerStartUp()
{
super();
}
/**
* setServices method comment.
*/
public void
setServices(weblogic.common.T3ServicesDef
arg1) {
}
/**
* startup method comment.
*/
public String startup(String arg1,
java.util.Hashtable prop) throws Exception
{
String resource = null;
try
{
Properties props
=NWProperties.getInstance();
Logger.init(props,null);
return Log4j
configuration
initialized.;
}
catch (Exception e)
{
System.out.println(Cannot
open
config file: +
resource);
return Log4j configuration
failed to
initialized.;
}
}
}
can anyone help me on this.
I get the most dreaded
log4j:WARN No appenders could be found for
logger
(epeople).
log4j:WARN Please initialize the log4j system
properly.
The sample output is as follows
Starting WebLogic Server
Aug 26, 2002 7:14:32 AM PDT Notice
Management
Loading configuration file
.\config\sudhendras\config.xml ...
Aug 26, 2002 7:14:36 AM PDT Notice
WebLogicServer Starting WebLogic Admin
Server sudhendrasAdmin for domain
sudhendras
log4j:WARN No appenders could be found for
logger
(epeople).
log4j:WARN Please initialize the log4j system
properly.
Aug 26, 2002 7:14:57 AM PDT Notice
Management
Application Poller started
for development server.
log4j: Parsing for [root] with
value=[DEBUG,stdout,
R
].
log4j: Level token is [DEBUG].
log4j: Category root set to DEBUG
log4j: Parsing appender named stdout.
log4j: Parsing layout options for stdout.
log4j: End of parsing for stdout.
log4j: Parsed stdout options.
log4j: Parsing appender named R.
log4j: Parsing layout options for R.
log4j: Setting property [conversionPattern] to
[%d
%-5p %c{1} %M - %m%n].
log4j: End of parsing for R.
log4j: Setting property [file] to
[c:/bea/wlserver6.1/config/sudhendras/epeople.
log].
log4j: Setting property [maxBackupIndex] to
[1].
log4j: Setting property [maxFileSize] to
[100KB].
log4j: setFile called:
c:/bea/wlserver6.1/config/sudhendras/epeople.log,
true
log4j: setFile ended
log4j: Parsed R options.
log4j: Parsing for [epeople] with
value=[DEBUG].
log4j: Level token is [DEBUG].
Re: Log4j SocketServer
On Tue, 2002-08-27 at 10:18, Kettal, El-Yamine wrote: Hi, I have the following question regarding the class SocketServer.java (used to allow TCP connection): In the function main, when a connection is accepted a thread is created at the following line: new Thread(new SocketNode(socket, h)).start(); As the reference to this thread is not kept any where in the program then this thread will be in the list of items to be cleaned by the garbage collector. Threads are only GC'ed when not running, i.e., when run() returns. Thus, when the socket node and the thread are both cleaned by GC then the TCP appender will have to reconnect again. My question is: Are the log4j TCP server and appender using one socket for several logging events (until the TCP appender is closed) or is the TCP server creating a socket node for every one or two logging events (depending on socket status (deleted or not)).? Thanks El-Yamine Kettal -- []'s Daniel Serodio -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Logging idioms or guidelines: anyone have some?
My boss is away, so I'm taking the opportuinity to clean up my code. I have a set of standards I use for style, formatting, documentation, naming etc. I also have a set of coding idioms I like to follow (Law of Demeter, code metric limits, etc). My problem is I don't yet have a set of logging idioms, and it shows up in my sporradic logging style. So I'm interested in a best practices of logging, or a logging standard. *Specifically* one that is based on something that makes it arguably superior to other standards. For example, do you log just before you do something: logger.debug(connecting to the database); or after logger.debug(connected to the database); or both? Do you log when you throw an exception, catch one, or both? etc... Preachers of aspect oriented programming might not mind seeing a logging statement at the entry and exit of every method. Some would certainly find this to be overkill. What do you all think? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Logging idioms or guidelines: anyone have some?
So I'm interested in a best practices of logging, or a logging standard. Have a look at ISO-23544-5. Seriously, appart from being consistant I doubt there is any single best way to do it. You should of course keep in mind why exactely it is that you are logging, as this influences the amount, distribution and form of log statements. Some use cases are: - Debug or monitor new or immature code - Generate reports on usage patterns - Trigger alerts on critical failures For example, do you log just before you do something: Obviously it's a good idea to log before and after operations that take a relatively long time or might hang or simply fail. log.debug(Connecting to x) try: ... catch: log.error(Couldn't connect to x, e) throw e log.info(Connected to x in + t + ms) I usually log errors when I catch them (and before I rethrow them, if), since more often than not I am not the one who threw them in the first place. -- Eric Jain -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Logging idioms or guidelines: anyone have some?
Hi, What you do, be consistent ;) That'll make it easier to understand and refactor later if necessary. Other than that, it's a matter of style. Sometimes it's a matter of personal style, sometimes organizational guidelines. There's an ISO standard somewhere about this, but I don't remember off the top of my head. For example, do you log just before you do something: logger.debug(connecting to the database); or after logger.debug(connected to the database); or both? Both, if it's a significant operation. Also for DEBUG-level statements, I always use logger.isDebugEnabled() around them for performance. It makes a big difference on large systems. Do you log when you throw an exception, catch one, or both? Both, on the principal that exceptions are serious things and you want to have caller (or thrower) as well as receiver (catcher) logging for them. There've been numerous times that I found having both logged together gives me significant context information for the exception. Preachers of aspect oriented programming might not mind seeing a logging statement at the entry and exit of every method. Some would certainly find this to be overkill. Overkill. But then again I'm very performance oriented. Like I said, it's a matter of style. The above are just IMHO. Yoav Shapira Millennium ChemInformatics This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
pure java log4j
Is there a version of log4j that is pure java. For e.g., the NTEventLogAppender requires a DLL. Is there a version that does not require any shared libraries / dll's ? Thanks, Madhav
Re: Article Info
Thanks for your comments and putting it on the site Ceki. Rgs Vikram - Original Message - From: Ceki Gülcü [EMAIL PROTECTED] To: Log4J Users List [EMAIL PROTECTED] Sent: Monday, August 26, 2002 10:47 PM Subject: Re: Article Info Vikram, Here are my comments: Note that for the build to be successful, you will need to have the Java Management Extensions (JMX) API in your classpath, as well. JMX API is not required to build log4j. The signs indicate the ordering of the logging that log4j follows. No signs appear in the text. Open up config-simple.properties in a text editor. It contains three lines (besides comments). The first line, log4j.rootLogger=debug, R tells log4j that the level of the root logger is at DEBUG. This is the default and is not required. The value after the comma, R, is required. It tells log4j that the root logger has an appender attached to it and that the name of the appender is R. The rest of the lines in this file tell log4j about the properties of this appender R. R is not the most descriptive name for a ConsoleAppender. In the following examples, appenders are also named as R. Thus, there is a risk that the reader might be induced to believe that R is a name with magical properties. A note of warning, though, about using the JDBCAppender in the current version of log4j: the documentation says that it is going to be completely replaced in the future with a revamped version. Although the inner working of this appender might change, the way one goes about using it is unlikely to change. There is a strong chance that JDBCAppender will be re-written with fixed columns which will result in a simpler interface. In the JDBC example you do not provide instructions for configuring the database table. You should at least say that it is the reader's responsibility to configure the table. So what code changes are needed to start logging to the database now? None! That is where the enormous power of log4j really manifests itself. To start logging to the database, we don't need to make any code changes. Albeit the WEB-INF/web.xml file has to be modified. I enjoyed reading your article. It is written in an easy-to-read style and covers much ground in a short amount of space. Moreover, your sample web-application conveys useful information succinctly. The log4j website has been updated with a link to your article. At 00:14 13.08.2002 +1000, you wrote: Hi All, I had put a link to a article I wrote on onjava.com. (http://www.onjava.com/pub/a/onjava/2002/08/07/log4j.html) in an earlier post. 1. I would really appreciate if I could get some honest feedback. :) This was my first article online and I just want to know whether to stop now before its too late. 2. How do I get about listing it on the log4j site? According to the info on the website, I just need to send a message to this list. Right ? Thanks for any answers/feedback. Regards, Vikram -- Ceki -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Logging from shared components
Hi all...
I'm a newbie to this list, so apologies up front if this question has been
asked and answered before. Here's a logging scenario that I'd like to
configure, but can't seem to find the magic to do so. Hoping some of you
here might help...
Let's say I have Servlet A and Servlet B deployed in some servlet container.
Each servlet's init() method configures log4j and appends a
RollingFileAppender with its own unique filename. The desire here is that
each servlet is a separate application and therefore has its own trace
logfile.
Now, let's say we've got some jar file that has a class named Foo. Foo has
a method called doSomething(). The class might look something like...
public class Foo {
private static Logger logger = Logger.getInstance(my.foo);
public void doSomething() {
logger.debug(You've invoked me!);
}
}
Now, let's say that each servlet's doPost() method creates an instance of
Foo and invokes it's doSomething() method. What I find happening is that a
POST to either servlet results in debug log event thrown from the shared
component being written to both servlet's log file.
How can I configure log4j so that logging events in the shared component
resulting from a POSTs to Servlet A are only written to Servlet A's log
file, and logging events in the shared component resulting from a POSTs to
Servlet B are only written to Servlet B's log file?
Thanks for the help...
Timothy
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
