It's never a good idea to use relative paths for resources in a webapp. You don't know where they'll end up. Especially if the server does internal "change working directory" operations at random intervals - which it's fully entitled to do, because "working directory" is not part of the
J2EE web application spec.
In my own case, I normally use the log4j.xml file in the WAR classpath and have a separate console logger which is used both by the
IDE and as part of the server log in production. Logs pertaining to various subsystems I made using absolute paths. Then again, the conventions of /var/log or /opt/product/log are fairly well-established under Linux, so I can demand those locations with relative impunity. If you're doing stuff that takes you into the Windows world, there are fewer established conventions.
So what I would probably do is simply define the log directory root for the app as a context environment entry variable, set up a JNDI lookup in the logger initialization code to obtain it, and construct the logger channels from there.
Since I typically have Spring managing my webapp assets, I'd first check the relevant Spring docs, since with any luck, that can all be done in the Sprint application context config file.