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 18:50:39 GMT
If you want to filter the logging events generated on the clients before they are remoted to
the server you will need to setup the logging configuration on the clients as appropriate.
There is no specific mechanism in log4net to distribute the configuration to the clients.


You can configure log4net programmatically and this may be a suitable option if you want to
have a remoting call to retrieve the logging levels for a client.

Alternatively you can pass a URI to XmlConfigurator.Configure. So you could publish a single
client log4net config and have all your clients request it from a web server.

Cheers,
Nicko

> -----Original Message-----
> From: Göran Roseen [mailto:goran@roseen.se] 
> Sent: 26 August 2005 16:12
> To: Log4NET User
> Subject: RE: Remoting architecture
> 
> 
> This sounds good, but what about thresholds/filters?
> Will the distributed loggers have to log all events, if the 
> thresholds/filters are applied on the logging server (after 
> being injected by the RemoteLoggingServerPlugin)?
> I guess in that case I need a simple way to distribute the 
> logger-specific parts of the config file to the distributed 
> servers...?
> 
> /Göran
> 
> BTW, Thanks for doing an excellent job! Your support on this 
> mailing list is simply beyond comparison...
> 
> 
> At 14:26 2005-08-26, you wrote:
> 
> >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, e.g.:
> >
> >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.
> >
> >Cheers,
> >Nicko
> >
> > > -----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
> > >
> > >
> >
> >
> >
> >--
> >Incoming mail is certified Virus Free...
> >Checked by AVG Anti-Virus.
> >Version: 7.0.344 / Virus Database: 267.10.16/83 - Release 
> Date: 2005-08-26
> >
> >
> >
> >
> >--
> >Incoming mail is certified Virus Free... (Eudora)
> >Checked by AVG Anti-Virus.
> >Version: 7.0.344 / Virus Database: 267.10.16/83 - Release 
> Date: 2005-08-26
> 
> 
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.344 / Virus Database: 267.10.16/83 - Release 
> Date: 2005-08-26
> 
> 
> 

Mime
View raw message