It's probably that the config file never gets put in the classpath when you run as a service. I think you've claimed previously that you verified that it was in the classpath, but that's hard to believe.
Why don't you do this. In some class (or a JSP), try to load up the config file as an inputstream from the classpath. If you are able to find it when running as a service, you will have ruled out this as a problem. However, if the inputstream is null, then it will be proven that the config file is not in the classpath. Jake Quoting Mirza Abbas Raza <[EMAIL PROTECTED]>: > Jacob, > > So, I got 1.2.14 version of log4j and ran the application as a service and > manually. I plugged in eclipse debugger to see where the problem was. I found > that when I run manually, the appenders are getting created. Specifically, > variable 'aai' has an instance of AppenderAttachableImpl for an appender, in > the callAppenders() api of Category class. However, 'aai' is null when the > application is run as windows service. Appreciate your help. > > Thanks, > Abbas > > > ----- Original Message ---- > From: Jacob Kjome <[EMAIL PROTECTED]> > To: Log4J Users List <[email protected]> > Sent: Monday, September 18, 2006 2:24:38 PM > Subject: Re: log4j doesn't log files when weblogic is run as a windows > service. > > > A few quesions/comments... > > 1. What version of Log4j are you using? I think at some point, there was a > feature implemented which allowed Log4j to create any needed directories. > This > hadn't been the case previously. I think it got implemented maybe post > 1.2.9, > but I'm not positive. So, it might make sense that the directories got > created. > > 2. Clearly Weblogic's service is setting the startup directory if you find > your > directories being created under "mydomain". > > 3. Are you sure that log4j.properties is getting picked up? Is it possible > some other config file is getting picked up? If log4j finds log4j.xml, it > will > be used in preference to log4j.properties. Also, try setting > log4j.debug=true. > Maybe you'll see some extra output. Add a console appender to make sure you > see > this output. It should turn up in Weblogic's console log file. > > > Jake > > Quoting Mirza Abbas Raza <[EMAIL PROTECTED]>: > > > So, Jake, here is what I did but didn't succeed. > > > > Excerpt from log4j.properties file. > > # Specify the R log file > > log4j.appender.R=org.apache.log4j.DailyRollingFileAppender > > log4j.appender.R.File=logs/node/mylog.log > > log4j.appender.DAILY.DatePattern='.'yyyy-MM-dd > > > > Scenario 1: Run as is. > > - checked C:\winnt\system32. > > - obviously no logs found. > > > > Scenario 2: Created directories logs/node in C:\winnt\system32. > > - stopped service and restarted. > > - no logs found in C:\winnt\system32\logs\node directory. > > > > Scenario 3: Changed log4j.appender.R.File=logs/node/mylog.log to > > D:\mydirectory\domains\mydomain/logs/node/mylog.log > > - stopped and restarted service. > > - no logs found in D:\mydirectory\domains\mydomain/logs/node/mylog.log. > > > > I couldn't find a way to specify the startup directory with the weblogic > > utility or the Java Service Wrapper and hence couldn't test it. However, I > > saw an interesting point in the properties for the service. > > "D:\mydirectory\domains\mydomain\wrapper.exe -s > > D:\mydirectory\domains\mydomain\conf\managedwrapper.conf". The logs/node > > directory is located in mydomain directory. Wouldn't this point the logs to > > the right directory? > > > > Thanks, > > Abbas > > > > > > ----- Original Message ---- > > From: Jacob Kjome <[EMAIL PROTECTED]> > > To: Log4J Users List <[email protected]>; Mirza Abbas Raza > > <[EMAIL PROTECTED]> > > Sent: Monday, September 18, 2006 11:57:20 AM > > Subject: Re: log4j doesn't log files when weblogic is run as a windows > > service. > > > > > > I'll bet they *do* get created. You just don't know where to look. What > > does > > your config look like? Does it use relative paths to the files? Keep in > > mind, > > relative paths are relative to the directory from which the JVM started. > So, > > if > > you start on the command line, the path in the config file is relative to > the > > current directory in the command shell. > > > > OTOH, When you start up using a service, unless you define the startup > > directory, it will default to "C:\WINDOWS\system32" (or the equivalent on > > your > > windows box). Furthermore, if your path includes a directory name, such as > > "./logs/mylog.log", and said directory doesn't exist already under > > "C:\WINDOWS\system32", then Log4j won't bother creating it for you. You > have > > to make sure it exists before Log4j can write to the location. > > > > Look into that and let us know what you find. > > > > Jake > > > > Quoting Mirza Abbas Raza <[EMAIL PROTECTED]>: > > > > > All, > > > > > > The log4j framework doesn't seem to write to the logs when weblogic is > run > > as > > > windows service. As I understand, the two things needed for the log4j > > > framework are: > > > - log4j.jar in classpath > > > - log4j.properties as -Dlog4j.configuration. It contains the necessary > > > configuration for logging. > > > > > > Both of the above mentioned artifacts are found correctly configured in > the > > > utilities that were used to create the windows service. I have used both > > bea > > > provided utility and Java Service Wrapper from Tanuki Software. When > > weblogic > > > is started after the service installation, log files that were supposed > to > > be > > > created by log4j don't appear. The ironic part is that when weblogic is > > > started manually, the log files do appear. Is there a known workaround > for > > > this scenario? I appreciate any help. > > > > > > Environment info: > > > OS - Windows 2000 server > > > JDK - 1.4.2 > > > Weblogic - 8.1 > > > log4j - 1.2.7 > > > > > > Thanks, > > > Abbas > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
