Re: [announce] Log4J Appender for Orion's application.log
Hi Curt, I agree with you, and that's why long ago we developed our own logging library, which rolls log files, logs to DB and can be configured "per web application". Now we are looking to migrating to Log4J, even though we still have to check if it will be worthwhile for us. I had a look at the new logging classes that are being included now in the JDK1.4, and it seems the tendence is to centralise everything, which I don't like. I understand though, that for maintenance reasons it might look very attractive. In our case, log configuration files are always located in the same place "/WEB-INF" and follow the same name pattern "*.logger.conf". We then redirect all the log files to the same directory, which is outside the deployed application directory, and you can have all the log files in one place while you know where everything is configured. Easy to find information, easy to mantain and, as configuration changes are detected in runtime, pretty useful. D. PD: I would also add that IMHO, web app security in the J2EE spec is very poorly defined, as specifying mappings in static files and letting containers implement role-users mappings makes applications rigid and non-portable. But that's another story ;). Curt Smith wrote: > > > Geoff Soutter wrote > >> >> >> I've hacked up an Orion Appender to allow you to log to the >> application.log file, via the Logger instance that Orion installs at >> java:comp/Logger. Here it is in all it's glory, use it however you wish. >> >> Cheers >> >> Geoff >> >> PS, did anyone figure out if it's possible to get orion to roll it's log >> files when they get too big? ;-) >> > How about Orion logs to a log4j output device instead of apps logging to > Orion's log > files? Or did I miss understand this functionality?? > > Personally I feel the new log4j 1.3 features that make it easier for > each application > to have it's xml config file in the .war / .ear so that apps can have > their own (separate) > log files from each other to be a very useful choice. > > My view of the problem of deploying and supporting a j2ee app is the few > features j2ee > put in the spec (a big zero) to allow debugging and logging of app, > feature, bean operations. > I feel we need to drill on the debugging problem until we have a > facility that supports > logging based on session ID, so that we can follow a particular user's > actions and > failures across a cluster and set of services. > > To me, moving to one log file for the universe is the wrong direction? > Any opinions? > > curt
Re: [announce] Log4J Appender for Orion's application.log
> reports itself in the correct context, so you can see how they happened. Yes and a nice feature. To be production quality we'd need file size roll-over and max-number of log file aging... Hmmm, this could be externalized in a script IF orion's logger didn't keep the file descriptor open between writes (probably does). curt
Re: [announce] Log4J Appender for Orion's application.log
Geoff Soutter wrote > > >I've hacked up an Orion Appender to allow you to log to the >application.log file, via the Logger instance that Orion installs at >java:comp/Logger. Here it is in all it's glory, use it however you wish. > >Cheers > >Geoff > >PS, did anyone figure out if it's possible to get orion to roll it's log >files when they get too big? ;-) > How about Orion logs to a log4j output device instead of apps logging to Orion's log files? Or did I miss understand this functionality?? Personally I feel the new log4j 1.3 features that make it easier for each application to have it's xml config file in the .war / .ear so that apps can have their own (separate) log files from each other to be a very useful choice. My view of the problem of deploying and supporting a j2ee app is the few features j2ee put in the spec (a big zero) to allow debugging and logging of app, feature, bean operations. I feel we need to drill on the debugging problem until we have a facility that supports logging based on session ID, so that we can follow a particular user's actions and failures across a cluster and set of services. To me, moving to one log file for the universe is the wrong direction? Any opinions? curt
[announce] Log4J Appender for Orion's application.log
Hi there,
I've hacked up an Orion Appender to allow you to log to the
application.log file, via the Logger instance that Orion installs at
java:comp/Logger. Here it is in all it's glory, use it however you wish.
Cheers
Geoff
PS, did anyone figure out if it's possible to get orion to roll it's log
files when they get too big? ;-)
import com.evermind.util.LogEvent;
import com.evermind.util.Logger;
import org.apache.log4j.AppenderSkeleton;
import org.apache.log4j.Layout;
import org.apache.log4j.PatternLayout;
import org.apache.log4j.spi.ErrorCode;
import org.apache.log4j.spi.LoggingEvent;
import org.apache.log4j.spi.ThrowableInformation;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;
/*
Example Test Code
Deploy OrionAppender with log4j in the Orion lib directory,
then add this code to an EJB or JSP and execute it.
Note it doesn't seem to be able to find a Logger instance when
running
in an application client, so in this case use a normal log4j
Appender.
Category log = Category.getInstance("for.bar.Category");
BasicConfigurator.resetConfiguration(); // for jsp reloading
BasicConfigurator.configure(new OrionAppender());
log.info("A test INFO message");
NDC.push("demo-ndc");
log.warn("A test WARN message with NDC");
NDC.pop();
log.fatal("A test FATAL message with exception", new
Exception("fatal"));
*/
public class OrionAppender extends AppenderSkeleton {
// NOTE: Most simple layouts are not useful for this Appender
because
// the design of log4j is such that Layouts are responsible for
adding
// line endings, and we require that the Layout not add line
endings.
// This is IMHO a design flaw in log4j...
// NOTE: Orion includes a "2/5/02 5:46 PM" format date in each log
entry.
// NOTE: Orion doesn't generate unique names for each thread, so the
thread
// name pattern entry is not much use.
// NOTE: Using a hardcoded layout now, can make this configurable
later.
// Basically it's "priority category [ndc]: message"
private static final Layout sLayout = new PatternLayout(
"%-5p %c{1} [%x]: %m");
private Logger iLogger;
public OrionAppender() {
try {
Context lContext = new InitialContext();
Object lBoundObject = lContext.lookup("java:comp/Logger");
iLogger = (Logger) PortableRemoteObject.narrow(lBoundObject,
Logger.class);
} catch (Exception e) {
errorHandler.error("Error finding Orion Logger for appender
[" +
name + "].", e, ErrorCode.GENERIC_FAILURE);
}
}
public boolean requiresLayout() {
// Tell the configurator we have our own hardcoded layout.
// See PropertyConfigurator for how this method is used.
return false;
}
protected void append(LoggingEvent event) {
if (iLogger == null) {
errorHandler.error("No Logger for appender [" + name +
"].");
return;
}
try {
LogEvent lEvent = null;
String lMessage = sLayout.format(event);
ThrowableInformation lInfo =
event.getThrowableInformation();
if (lInfo == null) {
lEvent = new LogEvent(lMessage);
} else {
lEvent = new LogEvent(lMessage, lInfo.getThrowable());
}
iLogger.log(lEvent);
} catch (Exception lEx) {
errorHandler.error("Could not log message in appender [" +
name
+ "].", lEx, ErrorCode.GENERIC_FAILURE);
}
}
public synchronized void close() {
iLogger = null;
}
}
