logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nicko Cadell" <ni...@neoworks.com>
Subject RE: Remoting architecture
Date Fri, 26 Aug 2005 12:26:13 GMT
You probably should just use the RemotingAppender.

Each of your client applications will need a log4net config file to specify the RemotingAppender
and where the server is. If you don't want to have this config file you could just setup the
RemotingAppender programmatically.

Your logging server application just needs to listen for remoted events using the log4net.Plugin.RemoteLoggingServerPlugin,

LogManager.GetRepository().PluginMap.Add(new RemoteLoggingServerPlugin("sinkUri"));

The RemoteLoggingServerPlugin will inject the remoted logging event into the local log4net
system as if it had been generated locally. All the normal log4net configuration applies to
these events as well as locally generated events. Therefore in your logging server log4net
config you specify the appenders that you want the output to go to.


> -----Original Message-----
> From: goran@roseen.se [mailto:goran@roseen.se] 
> Sent: 26 August 2005 00:14
> To: log4net-user@logging.apache.org
> Subject: Remoting architecture
> Dear all, I have a question of a general kind:
> How do you use log4net in a system with an architecture that 
> involves remoting?
> Consider, for example, an enterprise system consisting of a 
> webserver W (in the companys DMZ), an application server A 
> (on the inside) with business logic components that connects 
> to a database D.
> Sometimes the business logic components need to call 
> components on a server T that hosts some kind of third-party 
> software. Calls from W to A to T are using .Net Remoting, 
> calls to D are using Ado.Net.
> Yes, I realize that I reveal myself as a person that 
> previously has been forced to work in the ASP
> - COM - DCOM world... But the question is still valid, there 
> are still in the .Net world several reasons for wanting to 
> distribute your companys software over several servers.
> Consider some ways to go:
> - I can have a configuration file on every server, and let 
> every component do it's logging locally, but that means that 
> the logging info for a single call is spread over all 
> machines that it has passed, and it is up to me to merge it. 
> Changes in configuration will have to be duplicated over many 
> machines.
> - Next level might be to configure a remotingAppender on all 
> machines (all but the one where the logging will be 
> persisted), transmitting to one single machine that hosts a 
> RemotingServer. I am not so sure about how flexible this will 
> be though, the "local" config files will have to say "deliver 
> everything" to the RemotingAppender, but how much can we say 
> on the logging server, when the RemotingServer have picked up 
> the event?
> - An ugly solution might be to let every "called" component 
> create instances of class LoggingEvent (or similar), and 
> return an array of those. Then the main app takes that array 
> and logs them...
> - A dream solution might involve a special remoting-aware 
> LoggerManager class that takes care of retreiving and caching 
> the config files from the "logging server", and transparently 
> passes the events that shall be logged to a repository on the 
> logging server.
> I guess my wish list looks like this:
> * One single config file (to rule them all...and in the 
> darkness bind them... :-). At least only one place where 
> changes will be made.
> * One place where logging is "done". All appenders that can 
> work over the net (AdoNetAppender, NetSendAppender, 
> RemoteSyslogAppender etc) may of course so so, but file logs, 
> the windows event log and so on will be on this machine.
> * The code that logs will (preferably) not have to know it is 
> in a remoting scenario. An exciting problem is how the 
> decision wether to log or not will be done, if the logging 
> level, filters etc is set in the config file on another machine.
> * Minimal extra "fuzz" (managing clients and servers and 
> config files spread over a big organizations many servers)
> So what I really ask for here is; How do YOU do this, and how 
> would you LIKE to do it?
> There must be many ways do do this, what do you think the 
> pros and cons are?
> Sincerely,
> Göran Roseen

View raw message