Dear Dave,

I walk through that years before, too.

Yes - you can't let write different Log4J Appenders to the same file or you get 
this garbage.

Yes - you have property resolving here, but there are no properties you need.


We did a solution using an additional servlet called at application init that 
temporary define a property from the application parameters like virtual host 
and context path, write out the first logging entry to let initialize Log4J 
here, i.e. read the configuration file with the current parameter and finally 
undefine the parameter (for savety). This sequence has to by synchronized by an 
JVM-wide singleton to prevent parallel execution in case you have more than one 
application using this. Write me an email if I should search for the source 
code.


Another solution is to use a SocketAppender and an "central" receiver anywhere 
(running with a standalone JVM)

        <appender name="remote" class="org.apache.log4j.net.SocketAppender">
                <param name="RemoteHost" value="${log4j.remotehost}" />  <-- 
this name is NOT related to log4j, you may choose any you want.
                <param name="Port" value="${log4j.remoteport}" />
                <param name="ReconnectionDelay" value="10" />
                <param name="LocationInfo" value="false" />
        </appender>


        <appender name="async" class="org.apache.log4j.AsyncAppender">
                <param name="BufferSize" value="4096" />
                <param name="blocking" value="false" />
                <param name="LocationInfo" value="false" />
                <appender-ref ref="remote" />
        </appender>

        [...]

        <root>
                <level value="ERROR" />
                <appender-ref ref="file" />  <-- local file logging
                <appender-ref ref="async" />
        </root>

The AsyncAppender is chained on top to have a fuse not to block logging (and 
the application) in case of trouble with the receiver.


Greetings

Guido

>-----Original Message-----
>From: David Filip [mailto:dfi...@colornet.com]
>Sent: Monday, October 08, 2018 8:28 PM
>To: users@tomcat.apache.org
>Subject: log4j: Logging to same file from multiple contexts?
>
>Dear Tomcat Users,
>
>Apologies if this is more of a log4j question, but I thought that I'd start 
>here, in case Tomcat has any easy remedies.
>
>I have a common webapp that I deploy to multiple, different contexts.
>
>In log4j.properties, I have a few different log files defined, e.g., for 
>logins:
>
>log4j.appender.logins=org.apache.log4j.DailyRollingFileAppender
>log4j.appender.logins.file=${catalina.home}/logs/logins.log
>log4j.appender.logins.datePattern='.'yyyy-MM-dd
>log4j.appender.logins.append=true
>log4j.appender.logins.layout=org.apache.log4j.PatternLayout
>log4j.appender.logins.layout.ConversionPattern=[%d{MM/dd/yyyy HH:mm:ss}] [%p] 
>[%C{1}]: %m%n
>
>log4j.logger.com.colornet.CAP.Actions.LoginAction=info, logins
>log4j.logger.com.colornet.CAP.Util.LoginTokenTag=info, logins
>
>However, as you may have guessed, if I have the same log4j configuration file 
>for each context, the contexts tend to over-write
>each other.
>
>Is there any way to have the SAME log4j.properties deployed too multiple 
>contexts play nicely and not overwrite each other, but
>merely append each other?
>
>Extra credit question (although sounds even more like a log4j question, so 
>apologies): If not, is there any way to define the
>file path, e.g.:
>
>log4j.appender.logins.file=${catalina.home}/logs/logins.log
>
>to include the specific context?  I have found a few references on the 'Net, 
>e.g., ${contextPath}, ${servletName}, etc., which
>don't seem to work.
>
>My goal (desire?) is to have the same webapp and configuration and web.xml and 
>log4j.properties, etc., deployed to every web
>context, but not have one context overwrite another content's entries.
>
>Of course, as the Mick once said, "You can't always have what you want".
>
>Please let me know if this is possible.
>
>Thanks,
>
>Dave.
>
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to