date:20170811

Re: [log4net][log4php] Xml Config file

2017-08-11 Thread Mikael Ståldal

You have a file system, it is a storage. It has an index, a directory 
of files. Why not put the different configurations as separate files in 
a directory in the file system?



On 2017-08-09 07:34, Domínguez Moraleja, Jose Luis wrote:

I agree with you in a lot of things, but I think, maybe for my lack of 
experience talking in English, that you don't understand me at all.
1.- I would like just to give the possibility to share the same file, it is not 
mandatory but would be the default solution.
2.- What I want to share is just the "storage", in this case an XmlFile

In order to do this I think that as any storage system does we need an index, this 
index is  tag.
There you indicate the node of each logging subsystem in this case  and 
there should be another for . How do you indicate this? Is not what I'm 
proposing as I don't know it deeply, maybe a fullpath to the node, maybe just one tag  
don't know what is the best way.

Inside each tag, each one could still be using whatever attributes they use, I 
think what they are using now would be fine.

There's no reason to share appenders or other things, I'm not talking about 
this, just what I hope I explain now better.

Saludos,
Jose


-Mensaje original-
De: Dominik Psenner [mailto:dpsen...@gmail.com]
Enviado el: martes, 8 de agosto de 2017 14:45
Para: dev@logging.apache.org
Asunto: RE: [log4net][log4php] Xml Config file

There is at the moment only the idea of a common logging configuration 
specification for all the logging services subprojects. Note that this topic 
sounds like a great idea at first but gets complicated really quickly when 
thinking about all the different appenders, different notions about classes and 
namespaces or even differences in the environments like how settings are saved 
and retrieved. Storing the configuration in xml is not on all platforms the 
first choice. Because of these differences the different logging subprojects 
have evolved and they only share one thing:
they are there to provide a logging framework that fits into the environments 
where they run.

You could base your configuration files on a common configuration file and 
generate one for log4net and one for log4php during the release or deployment 
process. However i doubt the effort outweighs the benefits because every 
installation needs something slightly different. Further, when investigating an 
issue in backend A it should not affect backend B or frontend C and no longer 
be replaced by the default configuration on an update.

Last but not least, I would like to mention that decoupling applications is a 
great thing. A strongly coupled application is hard to maintain and refactor. 
And yes, I've been in such a situation and got no t-shirt. This is what I've 
learned back then:

https://en.m.wikipedia.org/wiki/Separation_of_concerns

As you say, you have two systems running on the same machine and they are two systems 
that are related, but developers and devops should care where they relate. Where they 
"communicate", there should be an API and the surface of both should be as 
small as possible. Hidden dependencies is not a great thing because it makes space for 
culprits and pitfalls.

On 8 Aug 2017 8:16 a.m., "Domínguez Moraleja, Jose Luis" < 
jldomingue...@sice.com> wrote:


That is not correct because your base "is what typically happens" is
not really/fully true.
We have the two system running in the same machine (not matter if they
are separate, just take care) and also they are related.
The difference between them is the business that they cover.
One of them is used for configuration and the other is for the
business itself.

The more we spread configuration the more difficult to maintain. (This
two systems are the base unit of lot of systems.)

And that's why we want to use just one file, and XML support this very
well, and also in log4net you can see that they thought about it and
you can embed your configuration following the example I gave, but php
does not allow it as it doesn't manage  tag. Well I
think this is the problem, but not quite sure. That's why I ask how
can I do this, I have a solution but I don't think it is the right way to do 
things.



Saludos,
Jose

-Mensaje original-
De: Dominik Psenner [mailto:dpsen...@gmail.com] Enviado el: lunes, 7
de agosto de 2017 21:16
Para: dev@logging.apache.org
Asunto: Re: [log4net][log4php] Xml Config file

To me this sounds rather strange because it sounds like a mix-up of
unrelated applications. Let me explain my reasoning..

Typically, log4net would run on an entirely different machine than
where log4php runs (i.e. apache2). At least it would not coexist
within an
apache2 process since apache2 would not run dotnet assemblies as far
as I am aware of. So there are at least two completely unrelated
processes sourcing one and the same configuration file. It's like
apache2 reading the postfix configuration, isn't it?

2017-08-07 17:09 GMT+02:00 Matt Sicker :

[jira] [Updated] (LOG4J2-2007) Async logger with SMTP appender looses ThreadContext values in PatternLayout

2017-08-11 Thread fabrizio giustina (JIRA)


 [ 
https://issues.apache.org/jira/browse/LOG4J2-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

fabrizio giustina updated LOG4J2-2007:
--
Summary: Async logger with SMTP appender looses ThreadContext values in 
PatternLayout  (was: Async logger loose ThreadContext values for header/footer)

> Async logger with SMTP appender looses ThreadContext values in PatternLayout
> 
>
> Key: LOG4J2-2007
> URL: https://issues.apache.org/jira/browse/LOG4J2-2007
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: fabrizio giustina
>Priority: Minor
>
> ThreadContext values seems not handled properly in pattern/header/footer 
> properties of PatternLayout when using async logging with a SMTP appender.
> Tested with a SMTP appended with a pattern layout: header is populated 
> property in sync mode but it doesn't work anymore when switching to async 
> (both using an Async appender than switching to async globally)
> This is a simple appender configuration that shows this behaviour:
> {noformat}
>  from="TESTn...@example.com" smtpHost="localhost" smtpPort="25" 
> ignoreExceptions="false" subject="MDCSUBJECT%X{MDC1} %m">
>   
> 
> 
>   
> 
> {noformat}
> a simple:
> {noformat}
> ThreadContext.put("MDC1", "***testmdc***");
> log.error("test message");
> {noformat}
> which goes directly to the sync-mail appender leads to the following result:
> {noformat}
> subject: MDCSUBJECT***testmdc*** test message 
> body: 
>  ===
>  MDC1HEADER=***testmdc***
>  ===
> {noformat}
> as you can see the ThreadContext value is replace in both the subject (built 
> with the "subject" attribute of the appender) and the body of the email, 
> generated using the "header" layout attribute.
> Doing the same though the "mail-async" appender leads instead to the 
> following result:
> {noformat}
> subject: MDCSUBJECT***testmdc*** test message 
> body: 
>  ===
>  MDC1HEADER=
>  ===
> {noformat}
> As you can see the subject of the email is still handled property (the 
> ThreadContext value has been filled although the message has been sent by a 
> separate thread) but the body of the email has lost any ThreadContext value. 
> I actually couldn't find any way at the moment to preserve ThreadContext 
> values in header/footer without keeping the smtp appender synchronous.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (LOG4J2-2007) Async logger loose ThreadContext values for header/footer

2017-08-11 Thread fabrizio giustina (JIRA)


 [ 
https://issues.apache.org/jira/browse/LOG4J2-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

fabrizio giustina updated LOG4J2-2007:
--
Description: 
ThreadContext values seems not handled properly in pattern/header/footer 
properties of PatternLayout when using async logging with a SMTP appender.
Tested with a SMTP appended with a pattern layout: header is populated property 
in sync mode but it doesn't work anymore when switching to async (both using an 
Async appender than switching to async globally)

This is a simple appender configuration that shows this behaviour:

{noformat}

  


  

{noformat}

a simple:
{noformat}
ThreadContext.put("MDC1", "***testmdc***");
log.error("test message");
{noformat}
which goes directly to the sync-mail appender leads to the following result:

{noformat}
subject: MDCSUBJECT***testmdc*** test message 
body: 
 ===
 MDC1HEADER=***testmdc***
 ===
{noformat}

as you can see the ThreadContext value is replace in both the subject (built 
with the "subject" attribute of the appender) and the body of the email, 
generated using the "header" layout attribute.

Doing the same though the "mail-async" appender leads instead to the following 
result:

{noformat}
subject: MDCSUBJECT***testmdc*** test message 
body: 
 ===
 MDC1HEADER=
 ===
{noformat}

As you can see the subject of the email is still handled property (the 
ThreadContext value has been filled although the message has been sent by a 
separate thread) but the body of the email has lost any ThreadContext value. I 
actually couldn't find any way at the moment to preserve ThreadContext values 
in header/footer without keeping the smtp appender synchronous.




  was:
ThreadContext values seems not handled properly in header/footer properties of 
PatternLayout when using async logging.
Tested with a SMTP appended with a pattern layout: header is populated property 
in sync mode but it doesn't work anymore when switching to async (both using an 
Async appender than switching to async globally)

This is a simple appender configuration that shows this behaviour:

{noformat}

  


  

{noformat}

a simple:
{noformat}
ThreadContext.put("MDC1", "***testmdc***");
log.error("test message");
{noformat}
which goes directly to the sync-mail appender leads to the following result:

{noformat}
subject: MDCSUBJECT***testmdc*** test message 
body: 
 ===
 MDC1HEADER=***testmdc***
 ===
{noformat}

as you can see the ThreadContext value is replace in both the subject (built 
with the "pattern" attribute of the appender) and the body of the email, 
generated using the "header" layout attribute.

Doing the same though the "mail-async" appender leads instead to the following 
result:

{noformat}
subject: MDCSUBJECT***testmdc*** test message 
body: 
 ===
 MDC1HEADER=
 ===
{noformat}

As you can see the subject of the email is still handled property (the 
ThreadContext value has been filled although the message has been sent by a 
separate thread) but the body of the email has lost any ThreadContext value. I 
actually couldn't find any way at the moment to preserve ThreadContext values 
in header/footer without keeping the smtp appender synchronous.





> Async logger loose ThreadContext values for header/footer
> -
>
> Key: LOG4J2-2007
> URL: https://issues.apache.org/jira/browse/LOG4J2-2007
> Project: Log4j 2
>  Issue Type: Bug
>Reporter: fabrizio giustina
>Priority: Minor
>
> ThreadContext values seems not handled properly in pattern/header/footer 
> properties of PatternLayout when using async logging with a SMTP appender.
> Tested with a SMTP appended with a pattern layout: header is populated 
> property in sync mode but it doesn't work anymore when switching to async 
> (both using an Async appender than switching to async globally)
> This is a simple appender configuration that shows this behaviour:
> {noformat}
>  from="TESTn...@example.com" smtpHost="localhost" smtpPort="25" 
> ignoreExceptions="false" subject="MDCSUBJECT%X{MDC1} %m">
>   
> 
> 
>   
> 
> {noformat}
> a simple:
> {noformat}
> ThreadContext.put("MDC1", "***testmdc***");
> log.error("test message");
> {noformat}
> which goes directly to the sync-mail appender leads to the following result:
> {noformat}
> subject: MDCSUBJECT***testmdc*** test message 
> body: 
>  ===
>  MDC1HEADER=***testmdc***
>  ===
> {noformat}
> as you can see the ThreadContext value is replace in both the subject (built 
>

[jira] [Created] (LOG4J2-2007) Async logger loose ThreadContext values for header/footer

2017-08-11 Thread fabrizio giustina (JIRA)

fabrizio giustina created LOG4J2-2007:
-

 Summary: Async logger loose ThreadContext values for header/footer
 Key: LOG4J2-2007
 URL: https://issues.apache.org/jira/browse/LOG4J2-2007
 Project: Log4j 2
  Issue Type: Bug
Reporter: fabrizio giustina
Priority: Minor


ThreadContext values seems not handled properly in header/footer properties of 
PatternLayout when using async logging.
Tested with a SMTP appended with a pattern layout: header is populated property 
in sync mode but it doesn't work anymore when switching to async (both using an 
Async appender than switching to async globally)

This is a simple appender configuration that shows this behaviour:

{noformat}

  


  

{noformat}

a simple:
{noformat}
ThreadContext.put("MDC1", "***testmdc***");
log.error("test message");
{noformat}
which goes directly to the sync-mail appender leads to the following result:

{noformat}
subject: MDCSUBJECT***testmdc*** test message 
body: 
 ===
 MDC1HEADER=***testmdc***
 ===
{noformat}

as you can see the ThreadContext value is replace in both the subject (built 
with the "pattern" attribute of the appender) and the body of the email, 
generated using the "header" layout attribute.

Doing the same though the "mail-async" appender leads instead to the following 
result:

{noformat}
subject: MDCSUBJECT***testmdc*** test message 
body: 
 ===
 MDC1HEADER=
 ===
{noformat}

As you can see the subject of the email is still handled property (the 
ThreadContext value has been filled although the message has been sent by a 
separate thread) but the body of the email has lost any ThreadContext value. I 
actually couldn't find any way at the moment to preserve ThreadContext values 
in header/footer without keeping the smtp appender synchronous.






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (LOG4NET-567) Use new csproj format to target multiple frameworks

2017-08-11 Thread Dominik Psenner (JIRA)


[ 
https://issues.apache.org/jira/browse/LOG4NET-567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16123062#comment-16123062
 ] 

Dominik Psenner commented on LOG4NET-567:
-

We do not have to build everything on one machine. Please have a look at the 
recent work I've done to build all targets except mono-2.0 on jenkins.

I like the idea of having one project file, but note also that the nant scripts 
do a lot. We will have to reimplement a great part of that functionality, or 
would the project file only contain the targets to build the codebase?

One thing that in my opinion definitely needs to be changed is that log4net 
does not use nuget to reference and restore its dependencies (nunit). Back then 
this functionality was not available, but changing this would make this a lot 
easier and fix some issues.

Last but not least I have set up the netstandard target to also test the 
assembly by executing dotnet test but it appears that it does not actually run 
the tests. Would you please have a look, since you are more experienced with 
netstandard?

If you clone the repository on github, base your modifications on the develop 
branch and file a pull request, jenkins should kick in and merge and build the 
pull request. This way you can also modify the Jenkinsfile and thus also the 
way how jenkins builds all the targets.

> Use new csproj format to target multiple frameworks
> ---
>
> Key: LOG4NET-567
> URL: https://issues.apache.org/jira/browse/LOG4NET-567
> Project: Log4net
>  Issue Type: Improvement
>Reporter: Peter Jas
>   Original Estimate: 4h
>  Remaining Estimate: 4h
>
> I have noticed that recently all the csprojs are converged to one monolithic 
> "old-style" csproj. It is an improvement but what about xproj and .NET Core?
> Instead of having xproj+project.json and csproj with two solution files and 
> multiple packages.config files in the repo, use modern csproj format, which 
> is compact, clear, able to target multiple platforms at once, does not 
> require any additional packages.config etc. file.
> bq. The idea is to remove netstandard directory from the root and maintain 
> only new-format csproj file.
> Additional advantange include easy to package for _all supported platforms_ 
> with ONE command: [{{dotnet 
> pack}}|https://docs.microsoft.com/en-us/dotnet/articles/core/tools/dotnet-pack].
> Example: 
> https://github.com/JamesNK/Newtonsoft.Json/blob/b311d91/Src/Newtonsoft.Json/Newtonsoft.Json.csproj.
>  James is supporting the whole JSON.NET for .NET Framework 2.0 to .NET 
> Standard 1.3 with a single new-csproj file.
> Sometimes we want to explicitly target mono, other times the neutral grouds 
> like PCL or NetStandard1.0 do the job. An example of explict targeting:
> {code:xml}
> net45;netstandard1.1;netstandard1.3;win81;MonoAndroid7;Xamarin.iOS10
> {code}
> see this example in action: 
> https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/0ae178520/src/Microsoft.Identity.Client/Microsoft.Identity.Client.csproj
> Also See: 
> https://docs.microsoft.com/en-us/dotnet/core/tools/project-json-to-csproj
> and http://www.natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/
> ---
> You can also try creating a new solution in VS2017 with dotnet core project 
> to get familiar with new csproj format. If you are not using VS2017 or VS 
> Code, then dotnet-cli can give a quick sneak peak:
> {code}
> mkdir test && cd $_
> dotnet new classlib -n mylib
> dotnet new console -n myapp
> dotnet add myapp.csproj reference mylib.csproj
> # dotnet restore && dotnet run
> {code}
> Then see the structure of mylib.csproj and myapp.csproj.
> ---
> Issues with new project system (which supports the new-csproj structure) can 
> be reported at https://github.com/dotnet/project-system. Note that in that 
> repo 15.3 milestone is next in line which will bring new features and fix 
> some existing complains: 
> https://github.com/dotnet/project-system/milestone/7. However the current 
> 15.2 version is working out fine for us in production.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [log4net][log4php] Xml Config file

[jira] [Updated] (LOG4J2-2007) Async logger with SMTP appender looses ThreadContext values in PatternLayout

[jira] [Updated] (LOG4J2-2007) Async logger loose ThreadContext values for header/footer

[jira] [Created] (LOG4J2-2007) Async logger loose ThreadContext values for header/footer

[jira] [Commented] (LOG4NET-567) Use new csproj format to target multiple frameworks

5 matches

Site Navigation

Mail list logo

Footer information