You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-user@logging.apache.org by Fredrik Pålsson <fr...@isgnordic.se> on 2022/08/06 20:04:51 UTC
Is it possible to have multiple plugins running in the same proces having separate log configs?
I’m developing plugins for a video management system. All plugins are loaded by a process that I have no control over. All plugins run in the same process.
When using log4net for logging this apparently can create problems. If one plugin initiates log4net and sets up loggers and possibly use the root logger and a little later another plugin does the same, it seems both plugins use the same root logger essentially resulting in both plugins logging to the same files or whatever appender is configured and with the same log level.
Is there a way to have multiple isolated instances of log4net running in the same process? Or is the solution to make distinct loggers for every plugin (not using the root logger), and hope that other plugins are not using logger with the same name?
Med vänlig hälsning
Fredrik Pålsson
Projektledare
ISG Nordic AB
+46 733-46 21 48
•
+46 42-36 21 48
fredrik.palsson@isgnordic.se • www.isgnordic.se
Sporthallsvägen 10, 263 35 Höganäs
Vi är en del av Lagercrantz Group.
Läs mer på www.lagercrantz.com
ISG Nordic AB är resultatet av en fusion mellan Nordic Alarm AB och ISG Systems AB, som skedde i april 2021.
Please note that this email may contain confidential information. If you have incorrectly received this message, please inform the sender of the error using the reply function. We also ask you to delete the email without forwarding it or copying it.
Re: Is it possible to have multiple plugins running in the same proces having separate log configs?
Posted by Dominik Psenner <dp...@gmail.com>.
Hi Anthony
Applications that load arbitrary assemblies without control are a nightmare
from many perspectives. Foremost I raise security concerns. However,
software can and should be made soft and thus can be adapted to satisfy all
kind of needs. There is no "one size fits all". Asking me, this is one of
the most intriguing niceties of software architecture, design,
implementation, deployment and maintenance.
I am confident one could find a solution to how configuring logging from
multiple files in a single application. AppDomain could be one piece of the
puzzle. It may however not be the smartest solution because it could be
easier to solve with multiple applications that share assemblies.
Warm regards,
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Sun, Aug 7, 2022, 20:43 Anthony Francisco <an...@recombulator.net> wrote:
> When I asked a similar question back in 2013 for my use case where there
> were multiple assemblies using Log4net and the conflicting
> confiurations/cross logging into the other log. The eventual answer that
> came back from this distribution list was that Log4Net was not designed for
> this kind of usage where you are not in control of the application loading
> the assemblies.
>
> For reference:
> How to configure log4net when using shared assemblies? (narkive.com)
> <https://log4net-user.logging.apache.narkive.com/tHUZpfR8/how-to-configure-log4net-when-using-shared-assemblies#post1>
>
> - Ants
>
> On Sun, Aug 7, 2022, at 07:21, Dominik Psenner wrote:
>
> You're very welcome.
>
> At some point it will be necessary to define how to implement the usecase.
> If you need even more flexibility and extendability, maybe even at runtime,
> it may be wise to not implement a single application with plugins but
> rather leverage flexibility through several applicationa that communicate
> via pub/sub protocols, something like mqtt or kafka.
>
> Happy coding!
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Sun, Aug 7, 2022, 09:59 Fredrik Pålsson <fr...@isgnordic.se>
> wrote:
>
>
> Thanks. I will look into this. However, I have no control over the parent
> process that loads plugins (for example my plugins), ruling out alternative
> 1.
>
> Again thanks!
>
> Med vänlig hälsning
>
> Fredrik Pålsson
> Projektledare
> ISG Nordic AB
> +46 733‑46 21 48
> •
> +46 42‑36 21 48
> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
> <https://www.isgnordic.se/>
> Sporthallsvägen 10, 263 35 Höganäs
>
>
> 7 aug. 2022 kl. 09:44 skrev Dominik Psenner <dp...@gmail.com>:
>
>
> Hi Frederik,
>
> I do believe you are actually observing an architectural problem.
> Apparently your plugins should ultimately live in an isolated environment.
> I propose some architectural and in terms very practical solutions:
>
> 1) run them in separate processes with a single process being the
> orchestrator/manager of all its childs
>
> 2) create a distinct AppDomain for each plugin
>
> Both solutions have obvious benefits but also their drawbacks.
> Communication between plugins would ultimately become an RPC interface, at
> least with marshalling of POCO objects. If that's unfeasible, for example
> because the usage requires extremely low latencies:
>
> 3) You could abstract the interfaces available to your plugins and use
> DependencyInjection to provide services like logging to plugins. This
> allows for more control, better interaction between plugins. This is an
> awesome design easily extensible to proposal 1 or 2. But note that a
> failing/buggy plugin could ultimately take down the entire process. If a
> plugin starts a background thread and crashes with an unhandles exception,
> it will take down the entire process!
>
> Happy coding!
> Dominik
>
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Sat, Aug 6, 2022, 22:05 Fredrik Pålsson <fr...@isgnordic.se>
> wrote:
>
> I’m developing plugins for a video management system. All plugins are
> loaded by a process that I have no control over. All plugins run in the
> same process.
>
>
>
> When using log4net for logging this apparently can create problems. If one
> plugin initiates log4net and sets up loggers and possibly use the root
> logger and a little later another plugin does the same, it seems both
> plugins use the same root logger essentially resulting in both plugins
> logging to the same files or whatever appender is configured and with the
> same log level.
>
>
>
> Is there a way to have multiple isolated instances of log4net running in
> the same process? Or is the solution to make distinct loggers for every
> plugin (not using the root logger), and hope that other plugins are not
> using logger with the same name?
>
>
>
>
> Med vänlig hälsning
>
> Fredrik Pålsson
> Projektledare
> ISG Nordic AB
> +46 733‑46 21 48
> •
> +46 42‑36 21 48
> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
> <https://www.isgnordic.se/>
> Sporthallsvägen 10, 263 35 Höganäs
>
> Vi är en del av Lagercrantz Group.
> Läs mer på *ww* <https://www.lagercrantz.com/>*w.lagercrantz.com*
> <http://www.lagercrantz.com/>
>
> <https://www.isgnordic.se/om-oss/jobba/>
>
> ISG Nordic AB är resultatet av en fusion mellan Nordic Alarm AB och ISG Systems AB, som skedde i april 2021.
> Please note that this email may contain confidential information. If you
> have incorrectly received this message, please inform the sender of the
> error using the reply function. We also ask you to delete the email without
> forwarding it or copying it.
>
>
>
Re: Is it possible to have multiple plugins running in the same proces having separate log configs?
Posted by Anthony Francisco <an...@recombulator.net>.
When I asked a similar question back in 2013 for my use case where there were multiple assemblies using Log4net and the conflicting confiurations/cross logging into the other log. The eventual answer that came back from this distribution list was that Log4Net was not designed for this kind of usage where you are not in control of the application loading the assemblies.
For reference:
How to configure log4net when using shared assemblies? (narkive.com) <https://log4net-user.logging.apache.narkive.com/tHUZpfR8/how-to-configure-log4net-when-using-shared-assemblies#post1>
- Ants
On Sun, Aug 7, 2022, at 07:21, Dominik Psenner wrote:
> You're very welcome.
>
> At some point it will be necessary to define how to implement the usecase. If you need even more flexibility and extendability, maybe even at runtime, it may be wise to not implement a single application with plugins but rather leverage flexibility through several applicationa that communicate via pub/sub protocols, something like mqtt or kafka.
>
> Happy coding!
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find them.
>
> On Sun, Aug 7, 2022, 09:59 Fredrik Pålsson <fr...@isgnordic.se> wrote:
>>
>> Thanks. I will look into this. However, I have no control over the parent process that loads plugins (for example my plugins), ruling out alternative 1.
>>
>> Again thanks!
>>
>> Med vänlig hälsning
>>
>> Fredrik Pålsson
>> Projektledare
>> ISG Nordic AB
>> +46 733‑46 21 48
>> •
>> +46 42‑36 21 48
>> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
>> Sporthallsvägen 10, 263 35 Höganäs
>>
>>
>> 7 aug. 2022 kl. 09:44 skrev Dominik Psenner <dp...@gmail.com>:
>>
>>
>> Hi Frederik,
>>
>> I do believe you are actually observing an architectural problem. Apparently your plugins should ultimately live in an isolated environment. I propose some architectural and in terms very practical solutions:
>>
>> 1) run them in separate processes with a single process being the orchestrator/manager of all its childs
>>
>> 2) create a distinct AppDomain for each plugin
>>
>> Both solutions have obvious benefits but also their drawbacks. Communication between plugins would ultimately become an RPC interface, at least with marshalling of POCO objects. If that's unfeasible, for example because the usage requires extremely low latencies:
>>
>> 3) You could abstract the interfaces available to your plugins and use DependencyInjection to provide services like logging to plugins. This allows for more control, better interaction between plugins. This is an awesome design easily extensible to proposal 1 or 2. But note that a failing/buggy plugin could ultimately take down the entire process. If a plugin starts a background thread and crashes with an unhandles exception, it will take down the entire process!
>>
>> Happy coding!
>> Dominik
>>
>> --
>> Sent from my phone. Typos are a kind gift to anyone who happens to find them.
>>
>> On Sat, Aug 6, 2022, 22:05 Fredrik Pålsson <fr...@isgnordic.se> wrote:
>>> I’m developing plugins for a video management system. All plugins are loaded by a process that I have no control over. All plugins run in the same process.____
>>> __ __
>>> When using log4net for logging this apparently can create problems. If one plugin initiates log4net and sets up loggers and possibly use the root logger and a little later another plugin does the same, it seems both plugins use the same root logger essentially resulting in both plugins logging to the same files or whatever appender is configured and with the same log level. ____
>>> __ __
>>> Is there a way to have multiple isolated instances of log4net running in the same process? Or is the solution to make distinct loggers for every plugin (not using the root logger), and hope that other plugins are not using logger with the same name?____
>>> __ __
>>> __ __
>>> Med vänlig hälsning
>>>
>>> Fredrik Pålsson
>>> Projektledare
>>> ISG Nordic AB
>>> +46 733‑46 21 48
>>> •
>>> +46 42‑36 21 48
>>> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
>>> Sporthallsvägen 10, 263 35 Höganäs
>>>
>>> Vi är en del av Lagercrantz Group.
>>> Läs mer på *ww* <https://www.lagercrantz.com/>*w.lagercrantz.com* <http://www.lagercrantz.com/>
>>>
<https://www.isgnordic.se/om-oss/jobba/>
>>> ISG Nordic AB är resultatet av en fusion mellan Nordic Alarm AB och ISG Systems AB, som skedde i april 2021.
>>> Please note that this email may contain confidential information. If you have incorrectly received this message, please inform the sender of the error using the reply function. We also ask you to delete the email without forwarding it or copying it.
Re: Is it possible to have multiple plugins running in the same proces having separate log configs?
Posted by Dominik Psenner <dp...@gmail.com>.
You're very welcome.
At some point it will be necessary to define how to implement the usecase.
If you need even more flexibility and extendability, maybe even at runtime,
it may be wise to not implement a single application with plugins but
rather leverage flexibility through several applicationa that communicate
via pub/sub protocols, something like mqtt or kafka.
Happy coding!
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Sun, Aug 7, 2022, 09:59 Fredrik Pålsson <fr...@isgnordic.se>
wrote:
> Thanks. I will look into this. However, I have no control over the parent
> process that loads plugins (for example my plugins), ruling out alternative
> 1.
>
> Again thanks!
>
> Med vänlig hälsning
>
> Fredrik Pålsson
> Projektledare
> ISG Nordic AB
> +46 733‑46 21 48
> •
> +46 42‑36 21 48
> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
> <https://www.isgnordic.se/>
> Sporthallsvägen 10, 263 35 Höganäs
>
> 7 aug. 2022 kl. 09:44 skrev Dominik Psenner <dp...@gmail.com>:
>
>
> Hi Frederik,
>
> I do believe you are actually observing an architectural problem.
> Apparently your plugins should ultimately live in an isolated environment.
> I propose some architectural and in terms very practical solutions:
>
> 1) run them in separate processes with a single process being the
> orchestrator/manager of all its childs
> 2) create a distinct AppDomain for each plugin
>
> Both solutions have obvious benefits but also their drawbacks.
> Communication between plugins would ultimately become an RPC interface, at
> least with marshalling of POCO objects. If that's unfeasible, for example
> because the usage requires extremely low latencies:
>
> 3) You could abstract the interfaces available to your plugins and use
> DependencyInjection to provide services like logging to plugins. This
> allows for more control, better interaction between plugins. This is an
> awesome design easily extensible to proposal 1 or 2. But note that a
> failing/buggy plugin could ultimately take down the entire process. If a
> plugin starts a background thread and crashes with an unhandles exception,
> it will take down the entire process!
>
> Happy coding!
> Dominik
> --
> Sent from my phone. Typos are a kind gift to anyone who happens to find
> them.
>
> On Sat, Aug 6, 2022, 22:05 Fredrik Pålsson <fr...@isgnordic.se>
> wrote:
>
>> I’m developing plugins for a video management system. All plugins are
>> loaded by a process that I have no control over. All plugins run in the
>> same process.
>>
>>
>>
>> When using log4net for logging this apparently can create problems. If
>> one plugin initiates log4net and sets up loggers and possibly use the root
>> logger and a little later another plugin does the same, it seems both
>> plugins use the same root logger essentially resulting in both plugins
>> logging to the same files or whatever appender is configured and with the
>> same log level.
>>
>>
>>
>> Is there a way to have multiple isolated instances of log4net running in
>> the same process? Or is the solution to make distinct loggers for every
>> plugin (not using the root logger), and hope that other plugins are not
>> using logger with the same name?
>>
>>
>>
>>
>> Med vänlig hälsning
>>
>> Fredrik Pålsson
>> Projektledare
>> ISG Nordic AB
>> +46 733‑46 21 48
>> •
>> +46 42‑36 21 48
>> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
>> <https://www.isgnordic.se/>
>> Sporthallsvägen 10, 263 35 Höganäs
>> Vi är en del av Lagercrantz Group.
>> Läs mer på *ww* <https://www.lagercrantz.com/>*w.lagercrantz.com*
>> <http://www.lagercrantz.com/>
>> <https://www.isgnordic.se/om-oss/jobba/>
>>
>> ISG Nordic AB är resultatet av en fusion mellan Nordic Alarm AB och ISG Systems AB, som skedde i april 2021.
>> Please note that this email may contain confidential information. If you
>> have incorrectly received this message, please inform the sender of the
>> error using the reply function. We also ask you to delete the email without
>> forwarding it or copying it.
>>
>
Re: Is it possible to have multiple plugins running in the same proces having separate log configs?
Posted by Fredrik Pålsson <fr...@isgnordic.se>.
Thanks. I will look into this. However, I have no control over the parent process that loads plugins (for example my plugins), ruling out alternative 1.
Again thanks!
Med vänlig hälsning
Fredrik Pålsson
Projektledare
ISG Nordic AB
+46 733-46 21 48
•
+46 42-36 21 48
fredrik.palsson@isgnordic.se • www.isgnordic.se
Sporthallsvägen 10, 263 35 Höganäs
7 aug. 2022 kl. 09:44 skrev Dominik Psenner <dp...@gmail.com>:
Hi Frederik,
I do believe you are actually observing an architectural problem. Apparently your plugins should ultimately live in an isolated environment. I propose some architectural and in terms very practical solutions:
1) run them in separate processes with a single process being the orchestrator/manager of all its childs
2) create a distinct AppDomain for each plugin
Both solutions have obvious benefits but also their drawbacks. Communication between plugins would ultimately become an RPC interface, at least with marshalling of POCO objects. If that's unfeasible, for example because the usage requires extremely low latencies:
3) You could abstract the interfaces available to your plugins and use DependencyInjection to provide services like logging to plugins. This allows for more control, better interaction between plugins. This is an awesome design easily extensible to proposal 1 or 2. But note that a failing/buggy plugin could ultimately take down the entire process. If a plugin starts a background thread and crashes with an unhandles exception, it will take down the entire process!
Happy coding!
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find them.
On Sat, Aug 6, 2022, 22:05 Fredrik Pålsson <fr...@isgnordic.se>> wrote:
I’m developing plugins for a video management system. All plugins are loaded by a process that I have no control over. All plugins run in the same process.
When using log4net for logging this apparently can create problems. If one plugin initiates log4net and sets up loggers and possibly use the root logger and a little later another plugin does the same, it seems both plugins use the same root logger essentially resulting in both plugins logging to the same files or whatever appender is configured and with the same log level.
Is there a way to have multiple isolated instances of log4net running in the same process? Or is the solution to make distinct loggers for every plugin (not using the root logger), and hope that other plugins are not using logger with the same name?
Med vänlig hälsning
Fredrik Pålsson
Projektledare
ISG Nordic AB
+46 733‑46 21 48
•
+46 42‑36 21 48
fredrik.palsson@isgnordic.se<ma...@isgnordic.se> • www.isgnordic.se<https://www.isgnordic.se/>
Sporthallsvägen 10, 263 35 Höganäs
[cid:image667510.jpg@B7583BE6.A0544C5C]
Vi är en del av Lagercrantz Group.
Läs mer på ww<https://www.lagercrantz.com/>w.lagercrantz.com<http://www.lagercrantz.com/>
[cid:image758981.jpg@5BCDB18C.542CF725]
[cid:image356272.png@5DF305CC.6C82C68C]<https://www.isgnordic.se/om-oss/jobba/>
ISG Nordic AB är resultatet av en fusion mellan Nordic Alarm AB och ISG Systems AB, som skedde i april 2021.
Please note that this email may contain confidential information. If you have incorrectly received this message, please inform the sender of the error using the reply function. We also ask you to delete the email without forwarding it or copying it.
Re: Is it possible to have multiple plugins running in the same proces having separate log configs?
Posted by Dominik Psenner <dp...@gmail.com>.
Hi Frederik,
I do believe you are actually observing an architectural problem.
Apparently your plugins should ultimately live in an isolated environment.
I propose some architectural and in terms very practical solutions:
1) run them in separate processes with a single process being the
orchestrator/manager of all its childs
2) create a distinct AppDomain for each plugin
Both solutions have obvious benefits but also their drawbacks.
Communication between plugins would ultimately become an RPC interface, at
least with marshalling of POCO objects. If that's unfeasible, for example
because the usage requires extremely low latencies:
3) You could abstract the interfaces available to your plugins and use
DependencyInjection to provide services like logging to plugins. This
allows for more control, better interaction between plugins. This is an
awesome design easily extensible to proposal 1 or 2. But note that a
failing/buggy plugin could ultimately take down the entire process. If a
plugin starts a background thread and crashes with an unhandles exception,
it will take down the entire process!
Happy coding!
Dominik
--
Sent from my phone. Typos are a kind gift to anyone who happens to find
them.
On Sat, Aug 6, 2022, 22:05 Fredrik Pålsson <fr...@isgnordic.se>
wrote:
> I’m developing plugins for a video management system. All plugins are
> loaded by a process that I have no control over. All plugins run in the
> same process.
>
>
>
> When using log4net for logging this apparently can create problems. If one
> plugin initiates log4net and sets up loggers and possibly use the root
> logger and a little later another plugin does the same, it seems both
> plugins use the same root logger essentially resulting in both plugins
> logging to the same files or whatever appender is configured and with the
> same log level.
>
>
>
> Is there a way to have multiple isolated instances of log4net running in
> the same process? Or is the solution to make distinct loggers for every
> plugin (not using the root logger), and hope that other plugins are not
> using logger with the same name?
>
>
>
>
> Med vänlig hälsning
>
> Fredrik Pålsson
> Projektledare
> ISG Nordic AB
> +46 733‑46 21 48
> •
> +46 42‑36 21 48
> fredrik.palsson@isgnordic.se • *www.isgnordic.se*
> <https://www.isgnordic.se/>
> Sporthallsvägen 10, 263 35 Höganäs
> Vi är en del av Lagercrantz Group.
> Läs mer på *ww* <https://www.lagercrantz.com/>*w.lagercrantz.com*
> <http://www.lagercrantz.com/>
> <https://www.isgnordic.se/om-oss/jobba/>
>
> ISG Nordic AB är resultatet av en fusion mellan Nordic Alarm AB och ISG Systems AB, som skedde i april 2021.
> Please note that this email may contain confidential information. If you
> have incorrectly received this message, please inform the sender of the
> error using the reply function. We also ask you to delete the email without
> forwarding it or copying it.
>