I may not always have the option to set the property on the server where I deploy. We found a different solution - we get the hardcoded path from a properties file in resource path.
On Sun, Apr 18, 2010 at 1:14 PM, Jacob Kjome <[email protected]> wrote: > > Why don't you read a system property that can be set upon server startup? > For example... > > java -Dlog.dir=/path/to/log/dir MyServer > > You can reference this variable inside Properties and XML config using > ${log.dir} and for programmatic config using System.getProperty("log.dir"). > > Jake > > > On 4/17/2010 12:30 PM, Roman Sokolyuk wrote: > >> Hi, >> >> I have the following situation. >> I need to log all users login into the application AND in addition I need >> to >> log them into their own individual files. So I have one config file for >> the >> main log that will log everything, and I add appenders programmatically >> for >> the individual log files for each user who logs in. >> The problem that I am running into is that depending on how the >> application >> is deployed, I cannot know where the logs are going to go. >> If I specify no location at all, the for example when I deploy the >> application on Linux (I am using the Resin server) - the log files end up >> in the installation directory for the web server. >> On windows, they are nowhere to be found. >> Additionally, if the application does not reside in the webapps directory >> of >> the server but the server is started elsewhere and pointed to the root >> folder of the application - the logs are again, hard to find. >> >> I need to be able to specify explicitly where the logs are going to go, so >> that regardless of where or how I deploy the application, all I have to do >> is change for example the context init parameters in web.xml (or some >> other >> config file) and be able to direct the logs exactly where I want them to >> go >> on the file system. And I have to be able to do it both for the main >> logger >> and for the appenders that are added programmatically. So both in my Java >> code, and in the log4j.xml. >> >> >> Could you please suggest how this can be done? >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
