logging-log4net-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göran Roseen <go...@roseen.se>
Subject RE: Remoting architecture
Date Fri, 26 Aug 2005 15:12:09 GMT

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