The XXXin the first message will actually show (Florida web design)
The XXXin the first message will actually show the name of the logger for which no appenders were configured. 15.4.5.3 Specifying a relative versus an absolute path When you use a system property to configure the log4j configuration file within a web application, the file is relative to the web application by default. The following example tells log4j to search for a file called log4j.xml in the WEB-INF/classes directory for the web application: java -Dlog4j.configuration=log4j.xml Most containers use a separate class loader for each web application, and some containers may not allow the web applications to know about classes or JARs loaded by the container itself. However, if you need to use an absolute path, you can specify one like this: java -Dlog4j.configuration=file:/c:/dev/env/log4j.xml Be careful when using an absolute path because the configuration file is not relative to a web application, all web applications will share the same one. Generally speaking, specifying a relative path is much more flexible than using an absolute path because you can’t always guarantee the directory structure of all your target environments. 15.4.5.4 Synchronization issues There’s one more issue that you should be aware of when logging to resources such as filesystems. Even though log4j is able to handle multiple client threads using the same appender (because all threads are synchronized), if you have multiple appenders writing to the same resource or file, you will have unpredictable results. In other words, there is no synchronization between appenders, even within the same JVM. This really has nothing to do with a deficiency in the log4j design; it’s just a case of not being able to easily synchronize multiple writers to a resource. The easiest way to solve this problem is to ensure that if you have multiple appenders or web applications logging to the filesystem, you don’t allow them to log to the same file. If you do, you will probably experience synchronization-related issues. 15.4.6 Log File Rollover In a normal production environment, log files can grow quite large if not managed properly. If the logging threshold is set to DEBUGor INFO or if the files are not purged from time to time, the files can grow without bounds. It’s a good idea to periodically back up the log files and start again with an empty log file. For some production environments, this “rollover” period may be nightly; others may only need to perform this routine weekly. Unless you can shut down the application while you back up the log files, it’s very cumbersome to back them up manually. Fortunately, log4j provides a type of appender that automatically swaps the log file out with a new one while at the same time maintaining a backup of the old log file. The org.apache.log4j.DailyRollingFileAppender class provides the ability to log to
Note: If you are looking for cheap and reliable webhost to host and run your mysql application check mysql web server services.