>>> >>> On that same line, I also need to be able to configure logging for each >>> JettyContainer on each port (project), configuring the log name and >>> location. I >>> need separated log files, and I also need syslog facility. >> What is the syslog facility? Do you know if it is available in plain >> jetty? > > Plain jetty has it, only as built in to log4j. > Here is the sample: > > file: Jetty/extra/resources/log4j.xml > - > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> > <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/";; > debug="false"> > ... > <!-- Syslog events > <appender name="SYSLOG" class="org.apache.log4j.net.SyslogAppender"> > <param name="Facility" value="LOCAL7"/> > <param name="FacilityPrinting" value="true"/> > <param name="SyslogHost" value="localhost"/> > </appender> > --> > ... > </log4j:configuration> > - > > However, We use Syslog to send all our access logs to a centralized server. > Although geronimo.log, the "error" log, is log4j, configured in > var/log/server-log4j.properties - It looks like NCSARequestLog, the "access" > log, is not Log4j > > Do you know any more about this? > > Syslog is an operating system level logging mechanism. > OS application send their logs to the syslog daemon in addition to, or instead > of, to a file. > The syslog manages the log information, sending it to disk or over the network > to a centralized logging server. > > http://en.wikipedia.org/wiki/Syslog > > The syslog facility is something like a group. The group is configured to > operate in some fashion, so you can do something like send this facility to > this > log file, and send this facility to this centralized log server. >
This thread described how to set up separated logging for each container, which entailed deploying a gbean (which only contained a single plan.xml file) to configure a new instance of NCSARequestLog. Each instance is configured separately, and then referenced in the container configuration. One would likely want to deploy new instances of WebContainer and RequestLog together in a single gbean. As far as syslog support goes, there is none for access/request logs. Syslog exists in Jetty for Application/server logs however. There is now a Feature Request submitted to the Jetty Project: http://jira.codehaus.org/browse/JETTY-835 It entails a request to implement a new RequestLog with support for slf4j (http://www.slf4j.org/) and Logback (http://logback.qos.ch/). Logback support many appenders, with support for creating custom appenders (http://logback.qos.ch/manual/appenders.html) Among the supported appenders are: ConsoleAppender http://logback.qos.ch/manual/appenders.html#ConsoleAppender FileAppender http://logback.qos.ch/manual/appenders.html#FileAppender RollingFileAppender http://logback.qos.ch/manual/appenders.html#RollingFileAppender FixedWindowRollingPolicy http://logback.qos.ch/manual/appenders.html#FixedWindowRollingPolicy TimeBasedRollingPolicy http://logback.qos.ch/manual/appenders.html#TimeBasedRollingPolicy SizeBasedTriggeringPolicy http://logback.qos.ch/manual/appenders.html#SizeBasedTriggeringPolicy SocketAppender http://logback.qos.ch/manual/appenders.html#SocketAppender JMSAppenderBase http://logback.qos.ch/manual/appenders.html#JMSAppenderBase JMSTopicAppender http://logback.qos.ch/manual/appenders.html#JMSTopicAppender JMSQueueAppender http://logback.qos.ch/manual/appenders.html#JMSQueueAppender SMTPAppender http://logback.qos.ch/manual/appenders.html#SMTPAppender DBAppender http://logback.qos.ch/manual/appenders.html#DBAppender SyslogAppender http://logback.qos.ch/manual/appenders.html#SyslogAppender It has support for JMX: http://logback.qos.ch/manual/jmxConfig.html And slf4j supports Log4j for those needing that: http://www.slf4j.org/api/org/slf4j/impl/Log4jLoggerAdapter.html - What is also interesting, is Logback Context Selectors http://logback.qos.ch/manual/loggingSeparation.html This may seem like it can give us the ability to have one instance of Logback serving many different separated logging environments. We have discussed how Geronimo/Jetty might eventually support web application filtering in a single WebContainer. In this way a WebContainer can listen on two ports, and serve web applications on one port but not the other. With the current implementation of NCSARequestLog, both web applications (and thus also request traffic on both ports) can only log to one single log file as configured in the NCSARequestLog tied into the WebContainer. However! With Logback context selectors, it looks like it might be possible to free the web apps (and also request traffic by port) from this restriction. At first look of Logback, it looks like Geronimo could be configured with one single Jetty WebContainer, and one single RequestLog using Logback, but be able to log into separate files based on port and/or based on web application using Logback context selectors. -RG
