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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 26 August 2005 00:14
> To: [email protected]
> 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
