Administrator
|
Hi,
I'm used to use the error.log to quickly look at errors in case. It would be quite easy to add it again in log4j2.xml. Is there a reason it has been removed OOTB? Jacques |
On Sep 8, 2014, at 2:12 PM, Jacques Le Roux <[hidden email]> wrote: > Hi, > > I'm used to use the error.log to quickly look at errors in case. > > It would be quite easy to add it again in log4j2.xml. Is there a reason it has been removed OOTB? The only reason is to keep the default configuration as simple, generic and minimal as possible. As you said, it is very easy for each developer to customize to fit it to his/her own preferences. Jacopo > > Jacques |
Administrator
|
Le 08/09/2014 14:20, Jacopo Cappellato a écrit : > On Sep 8, 2014, at 2:12 PM, Jacques Le Roux <[hidden email]> wrote: > >> Hi, >> >> I'm used to use the error.log to quickly look at errors in case. >> >> It would be quite easy to add it again in log4j2.xml. Is there a reason it has been removed OOTB? > The only reason is to keep the default configuration as simple, generic and minimal as possible. As you said, it is very easy for each developer to customize to fit it to his/her own preferences. Then, if nobody mind, I'd like to re-add the error.log concept Jacques > > Jacopo > >> Jacques > > |
On Sep 8, 2014, at 3:51 PM, Jacques Le Roux <[hidden email]> wrote: > Then, if nobody mind, I'd like to re-add the error.log concept I prefer you don't but if I am the only one I would not object. Jacopo |
On 9/09/2014, at 2:59 am, Jacopo Cappellato <[hidden email]> wrote:
> > On Sep 8, 2014, at 3:51 PM, Jacques Le Roux <[hidden email]> wrote: > >> Then, if nobody mind, I'd like to re-add the error.log concept > > I prefer you don't but if I am the only one I would not object. > > Jacopo I spend a lot of time debugging production instances and I never use it, so I'd prefer if it wasn't there as well. Using grep to list errors is a simple alternative that doesn't require additional files. Individual errors are often worthless without the surrounding INFO and DEBUG information IMO. Regards Scott |
Administrator
|
Le 08/09/2014 23:31, Scott Gray a écrit : > On 9/09/2014, at 2:59 am, Jacopo Cappellato <[hidden email]> wrote: > >> On Sep 8, 2014, at 3:51 PM, Jacques Le Roux <[hidden email]> wrote: >> >>> Then, if nobody mind, I'd like to re-add the error.log concept >> I prefer you don't but if I am the only one I would not object. >> >> Jacopo > I spend a lot of time debugging production instances and I never use it, so I'd prefer if it wasn't there as well. Using grep to list errors is a simple alternative that doesn't require additional files. Individual errors are often worthless without the surrounding INFO and DEBUG information IMO. I had also my share of reading myself blind at production logs and I must admit I then rarely used the error.log, but indeed greped. Let me list the cases I found error.Log useful, first I must say my platform of choice is Windows. When in development and test phase, using either File Explorer on Windows (development) or WinSCP on servers (test). It's then the fastest way to get an idea on what is going wrong. The same applies with OFBiz demos on the OFBiz-VM at the ASF. Once the file (error.log) is open (I use Scite as local text editor) either from File Explorer or WinSCP, it's a breeze to refresh it, because normally this file is lighter than ofbiz.log (else you have a big problem). Also we removed console.log. In some cases I found it very convenient. On the other hand I can agree that having a lot of logs written can slow down the system. And I guess that's the reason why Jacopo and you are against multiplying them. I believe, contrary to console.log, simply re-adding error should not have an important impact in most circumstances, hopefully you have not that much error in your instance. The idea is I don't want to have to manually re-add it each time I want it. For console.log these cases are less frequent, so doing it by hand then will not be a problem. I will even maybe add a patch for console.log in the repo, ready to use... What others think? Jacques > > Regards > Scott > > > |
Hi Jaques,
I am not sure if this is helpful for your comments below .. but i know of multiple software packages (git for windows which has msysgit for example) that provide native linux tools on windows including grep and ssh (for local and remote work). Furthermore you can still download powerful text editors on windows. Vim for example, is extremely fast with massive text files which we opened in the past and regex through that thing is a breeze. So I guess I'm trying to emphasize that the OS choice is not a big issue with proper tools. Taher Alkhateeb On Sep 9, 2014 8:08 AM, "Jacques Le Roux" <[hidden email]> wrote: > > Le 08/09/2014 23:31, Scott Gray a écrit : > >> On 9/09/2014, at 2:59 am, Jacopo Cappellato <[hidden email]> >> wrote: >> >> On Sep 8, 2014, at 3:51 PM, Jacques Le Roux < >>> [hidden email]> wrote: >>> >>> Then, if nobody mind, I'd like to re-add the error.log concept >>>> >>> I prefer you don't but if I am the only one I would not object. >>> >>> Jacopo >>> >> I spend a lot of time debugging production instances and I never use it, >> so I'd prefer if it wasn't there as well. Using grep to list errors is a >> simple alternative that doesn't require additional files. Individual >> errors are often worthless without the surrounding INFO and DEBUG >> information IMO. >> > > I had also my share of reading myself blind at production logs and I must > admit I then rarely used the error.log, but indeed greped. Let me list the > cases I found error.Log useful, first I must say my platform of choice is > Windows. > When in development and test phase, using either File Explorer on Windows > (development) or WinSCP on servers (test). It's then the fastest way to get > an idea on what is going wrong. The same applies with OFBiz demos on the > OFBiz-VM at the ASF. Once the file (error.log) is open (I use Scite as > local text editor) either from File Explorer or WinSCP, it's a breeze to > refresh it, because normally this file is lighter than ofbiz.log (else you > have a big problem). > > Also we removed console.log. In some cases I found it very convenient. On > the other hand I can agree that having a lot of logs written can slow down > the system. And I guess that's the reason why Jacopo and you are against > multiplying them. I believe, contrary to console.log, simply re-adding > error should not have an important impact in most circumstances, hopefully > you have not that much error in your instance. > > The idea is I don't want to have to manually re-add it each time I want > it. For console.log these cases are less frequent, so doing it by hand then > will not be a problem. I will even maybe add a patch for console.log in the > repo, ready to use... > > What others think? > > Jacques > > >> Regards >> Scott >> >> >> >> |
In reply to this post by Jacques Le Roux
On Sep 9, 2014, at 7:08 AM, Jacques Le Roux <[hidden email]> wrote: > [...] On the other hand I can agree that having a lot of logs written can slow down the system. And I guess that's the reason why Jacopo and you are against multiplying them. [...] This is not what I wrote in my previous email; quoting here for your convenience: "The only reason is to keep the default configuration as simple, generic and minimal as possible. As you said, it is very easy for each developer to customize to fit it to his/her own preferences." > I believe, contrary to console.log, simply re-adding error should not have an important impact in most circumstances, hopefully you have not that much error in your instance. > > The idea is I don't want to have to manually re-add it each time I want it. For console.log these cases are less frequent, so doing it by hand then will not be a problem. I will even maybe add a patch for console.log in the repo, ready to use... Please, don't do this: let's all try to keep the public repo as clean as possible without adding stuff to facilitate our personal workflow; for example, the commit you did yesterday to .svnignore and .gitignore is really ugly (your commit message was "I found convenient to have an icon in Windows File explorer for my local OFBiz checkouts, must ignore it"): I didn't comment because I don't want to be too peaky but in my opinion it is a symptom of a wrong concept of the repository. I have plenty of tools and scripts in my local environment that are useful to me but not a good fit for the project and I don't put them in the repository just because it will be easier for me to find them there every time I do a checkout. Jacopo |
Jacopo,
Thank you for mentioning the .svnignore and .gitignore commit - that bothers me too. We should be ignoring things in the repo, not our personal modifications. Adrian Crum Sandglass Software www.sandglass-software.com On 9/9/2014 7:20 AM, Jacopo Cappellato wrote: > > On Sep 9, 2014, at 7:08 AM, Jacques Le Roux <[hidden email]> wrote: > >> [...] On the other hand I can agree that having a lot of logs written can slow down the system. And I guess that's the reason why Jacopo and you are against multiplying them. [...] > > This is not what I wrote in my previous email; quoting here for your convenience: > > "The only reason is to keep the default configuration as simple, generic and minimal as possible. As you said, it is very easy for each developer to customize to fit it to his/her own preferences." > >> I believe, contrary to console.log, simply re-adding error should not have an important impact in most circumstances, hopefully you have not that much error in your instance. >> >> The idea is I don't want to have to manually re-add it each time I want it. For console.log these cases are less frequent, so doing it by hand then will not be a problem. I will even maybe add a patch for console.log in the repo, ready to use... > > Please, don't do this: let's all try to keep the public repo as clean as possible without adding stuff to facilitate our personal workflow; for example, the commit you did yesterday to .svnignore and .gitignore is really ugly (your commit message was "I found convenient to have an icon in Windows File explorer for my local OFBiz checkouts, must ignore it"): I didn't comment because I don't want to be too peaky but in my opinion it is a symptom of a wrong concept of the repository. I have plenty of tools and scripts in my local environment that are useful to me but not a good fit for the project and I don't put them in the repository just because it will be easier for me to find them there every time I do a checkout. > > Jacopo > |
Administrator
|
In reply to this post by taher
Thanks Taher,
I'm aware of those and I sometimes indeed use msysgit for some exotic git commands (there are so much), though I prefer to use TortoiseGit in much cases. Scite is also fast and includes regex of course, I can use also Eclipse for that and Putty for SSH (I even recently found Windows has an excellent VPN client embedded)... What I want to emphasize is no, Windows users are not idiots, and no, I don't want to learl Vim :p Jacques Le 09/09/2014 07:39, Taher Alkhateeb a écrit : > Hi Jaques, > > I am not sure if this is helpful for your comments below .. but i know of > multiple software packages (git for windows which has msysgit for example) > that provide native linux tools on windows including grep and ssh (for > local and remote work). > > Furthermore you can still download powerful text editors on windows. Vim > for example, is extremely fast with massive text files which we opened in > the past and regex through that thing is a breeze. > > So I guess I'm trying to emphasize that the OS choice is not a big issue > with proper tools. > > Taher Alkhateeb > On Sep 9, 2014 8:08 AM, "Jacques Le Roux" <[hidden email]> > wrote: > >> Le 08/09/2014 23:31, Scott Gray a écrit : >> >>> On 9/09/2014, at 2:59 am, Jacopo Cappellato <[hidden email]> >>> wrote: >>> >>> On Sep 8, 2014, at 3:51 PM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>> Then, if nobody mind, I'd like to re-add the error.log concept >>>> I prefer you don't but if I am the only one I would not object. >>>> >>>> Jacopo >>>> >>> I spend a lot of time debugging production instances and I never use it, >>> so I'd prefer if it wasn't there as well. Using grep to list errors is a >>> simple alternative that doesn't require additional files. Individual >>> errors are often worthless without the surrounding INFO and DEBUG >>> information IMO. >>> >> I had also my share of reading myself blind at production logs and I must >> admit I then rarely used the error.log, but indeed greped. Let me list the >> cases I found error.Log useful, first I must say my platform of choice is >> Windows. >> When in development and test phase, using either File Explorer on Windows >> (development) or WinSCP on servers (test). It's then the fastest way to get >> an idea on what is going wrong. The same applies with OFBiz demos on the >> OFBiz-VM at the ASF. Once the file (error.log) is open (I use Scite as >> local text editor) either from File Explorer or WinSCP, it's a breeze to >> refresh it, because normally this file is lighter than ofbiz.log (else you >> have a big problem). >> >> Also we removed console.log. In some cases I found it very convenient. On >> the other hand I can agree that having a lot of logs written can slow down >> the system. And I guess that's the reason why Jacopo and you are against >> multiplying them. I believe, contrary to console.log, simply re-adding >> error should not have an important impact in most circumstances, hopefully >> you have not that much error in your instance. >> >> The idea is I don't want to have to manually re-add it each time I want >> it. For console.log these cases are less frequent, so doing it by hand then >> will not be a problem. I will even maybe add a patch for console.log in the >> repo, ready to use... >> >> What others think? >> >> Jacques >> >> >>> Regards >>> Scott >>> >>> >>> >>> |
Administrator
|
In reply to this post by Adrian Crum-3
Yes, I was maybe abusing there indeed. But note that I did not add a tool in the repo, only added something to ignore it. This should be transparent
to everybody. Like for the desktop.ini entry in the .*ignore files I don't see a reason to not add a readymade patch for console.log. Again, it would be transparent to everybody, but convenient for those who want it. I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? Now about the error.log, I will re-add it. I think it makes sense and is not really complicating log4j2.xml. Jacques Le 09/09/2014 08:30, Adrian Crum a écrit : > Jacopo, > > Thank you for mentioning the .svnignore and .gitignore commit - that bothers me too. We should be ignoring things in the repo, not our personal > modifications. > > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 9/9/2014 7:20 AM, Jacopo Cappellato wrote: >> >> On Sep 9, 2014, at 7:08 AM, Jacques Le Roux <[hidden email]> wrote: >> >>> [...] On the other hand I can agree that having a lot of logs written can slow down the system. And I guess that's the reason why Jacopo and you >>> are against multiplying them. [...] >> >> This is not what I wrote in my previous email; quoting here for your convenience: >> >> "The only reason is to keep the default configuration as simple, generic and minimal as possible. As you said, it is very easy for each developer >> to customize to fit it to his/her own preferences." >> >>> I believe, contrary to console.log, simply re-adding error should not have an important impact in most circumstances, hopefully you have not that >>> much error in your instance. >>> >>> The idea is I don't want to have to manually re-add it each time I want it. For console.log these cases are less frequent, so doing it by hand >>> then will not be a problem. I will even maybe add a patch for console.log in the repo, ready to use... >> >> Please, don't do this: let's all try to keep the public repo as clean as possible without adding stuff to facilitate our personal workflow; for >> example, the commit you did yesterday to .svnignore and .gitignore is really ugly (your commit message was "I found convenient to have an icon in >> Windows File explorer for my local OFBiz checkouts, must ignore it"): I didn't comment because I don't want to be too peaky but in my opinion it is >> a symptom of a wrong concept of the repository. I have plenty of tools and scripts in my local environment that are useful to me but not a good fit >> for the project and I don't put them in the repository just because it will be easier for me to find them there every time I do a checkout. >> >> Jacopo >> > |
On Sep 9, 2014, at 9:52 AM, Jacques Le Roux <[hidden email]> wrote:
> I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? This is ridiculous, Jacques. This is not about the slimdown (crusade?), this ended up months ago. This is all about writing and maintaining good, well-crafted artifacts and code. The current OFBiz trunk is still a great mess and I am surprised (and a bit concerned) that you think we are going too far in the attempt to keep things clean. Jacopo |
Plus, that ignore setting commit benefits only one person - Jacques.
That concerns me because it appears Jacques considers the trunk to be his personal project. Adrian Crum Sandglass Software www.sandglass-software.com On 9/9/2014 9:12 AM, Jacopo Cappellato wrote: > On Sep 9, 2014, at 9:52 AM, Jacques Le Roux <[hidden email]> wrote: > >> I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? > > This is ridiculous, Jacques. This is not about the slimdown (crusade?), this ended up months ago. This is all about writing and maintaining good, well-crafted artifacts and code. The current OFBiz trunk is still a great mess and I am surprised (and a bit concerned) that you think we are going too far in the attempt to keep things clean. > > Jacopo > |
Administrator
|
In reply to this post by Jacopo Cappellato-3
Le 09/09/2014 10:12, Jacopo Cappellato a écrit : > On Sep 9, 2014, at 9:52 AM, Jacques Le Roux <[hidden email]> wrote: > >> I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? > This is ridiculous, Jacques. This is not about the slimdown (crusade?), this ended up months ago. This is all about writing and maintaining good, well-crafted artifacts and code. The current OFBiz trunk is still a great mess and I am surprised (and a bit concerned) that you think we are going too far in the attempt to keep things clean. What I mean is I don't see how and why (re-)adding error.log in log4j2.xml will make it messy, really are we not splitting hairs here? If you told me, "this will slow down and the system" or something like that I could understand. But I explained why it should not, except if you have an extremely big issue and then this big issue would be your concern, not the error.log which would only be the symptom. > > Jacopo > > > |
Administrator
|
In reply to this post by Adrian Crum-3
Le 09/09/2014 10:27, Adrian Crum a écrit : > Plus, that ignore setting commit benefits only one person - Jacques. That concerns me because it appears Jacques considers the trunk to be his > personal project. I surely not, it's only that Git is missing the ignore-on-commit svn feature and I dislike having to uncheck, take care of it each time I need to commit :/ If you guys can't stand having desktop.ini in .gitignore file (it's a property in svn) I willl remove them, but seriously this is all completely ridiculous! Jacques > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 9/9/2014 9:12 AM, Jacopo Cappellato wrote: >> On Sep 9, 2014, at 9:52 AM, Jacques Le Roux <[hidden email]> wrote: >> >>> I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? >> >> This is ridiculous, Jacques. This is not about the slimdown (crusade?), this ended up months ago. This is all about writing and maintaining good, >> well-crafted artifacts and code. The current OFBiz trunk is still a great mess and I am surprised (and a bit concerned) that you think we are going >> too far in the attempt to keep things clean. >> >> Jacopo >> > |
In reply to this post by Jacques Le Roux
Jacques,
you are clearly not reading what I and others wrote. Jacopo On Sep 9, 2014, at 10:39 AM, Jacques Le Roux <[hidden email]> wrote: > > Le 09/09/2014 10:12, Jacopo Cappellato a écrit : >> On Sep 9, 2014, at 9:52 AM, Jacques Le Roux <[hidden email]> wrote: >> >>> I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? >> This is ridiculous, Jacques. This is not about the slimdown (crusade?), this ended up months ago. This is all about writing and maintaining good, well-crafted artifacts and code. The current OFBiz trunk is still a great mess and I am surprised (and a bit concerned) that you think we are going too far in the attempt to keep things clean. > > What I mean is I don't see how and why (re-)adding error.log in log4j2.xml will make it messy, really are we not splitting hairs here? > If you told me, "this will slow down and the system" or something like that I could understand. But I explained why it should not, except if you have an extremely big issue and then this big issue would be your concern, not the error.log which would only be the symptom. > >> >> Jacopo >> >> >> |
Administrator
|
My answer was
>What I mean is I don't see how and why (re-)adding error.log in log4j2.xml will make it messy I just added a point about performance issue because I knew it would be the next argument on the table. Adding few lines in log4j2.xml does not stand as an argument to me. Jacques Le 09/09/2014 10:55, Jacopo Cappellato a écrit : > Jacques, > > you are clearly not reading what I and others wrote. > > Jacopo > > On Sep 9, 2014, at 10:39 AM, Jacques Le Roux <[hidden email]> wrote: > >> Le 09/09/2014 10:12, Jacopo Cappellato a écrit : >>> On Sep 9, 2014, at 9:52 AM, Jacques Le Roux <[hidden email]> wrote: >>> >>>> I understand you want to keep things as clean as possible, but are we not going too far in our slimdown crusade? >>> This is ridiculous, Jacques. This is not about the slimdown (crusade?), this ended up months ago. This is all about writing and maintaining good, well-crafted artifacts and code. The current OFBiz trunk is still a great mess and I am surprised (and a bit concerned) that you think we are going too far in the attempt to keep things clean. >> What I mean is I don't see how and why (re-)adding error.log in log4j2.xml will make it messy, really are we not splitting hairs here? >> If you told me, "this will slow down and the system" or something like that I could understand. But I explained why it should not, except if you have an extremely big issue and then this big issue would be your concern, not the error.log which would only be the symptom. >> >>> Jacopo >>> >>> >>> > > |
Jacques,
You still are not understanding what you are saying, and you are not understanding our replies. You are saying: 1. You want to change log settings because it benefits Jacques. 2. You want to change ignore settings because it benefits Jacques. Jacopo and I are saying: 1. Every developer wants different log settings, so they are free to modify them on their local copy. 2. Every developer uses different tools and shortcuts, so they are free to add them to their local copy. 3. Since every developer is different, we should leave #1 and #2 out of the trunk. Adrian Crum Sandglass Software www.sandglass-software.com On 9/9/2014 10:09 AM, Jacques Le Roux wrote: > My answer was > >What I mean is I don't see how and why (re-)adding error.log in > log4j2.xml will make it messy > > I just added a point about performance issue because I knew it would be > the next argument on the table. Adding few lines in log4j2.xml does not > stand as an argument to me. > > Jacques > > Le 09/09/2014 10:55, Jacopo Cappellato a écrit : >> Jacques, >> >> you are clearly not reading what I and others wrote. >> >> Jacopo >> >> On Sep 9, 2014, at 10:39 AM, Jacques Le Roux >> <[hidden email]> wrote: >> >>> Le 09/09/2014 10:12, Jacopo Cappellato a écrit : >>>> On Sep 9, 2014, at 9:52 AM, Jacques Le Roux >>>> <[hidden email]> wrote: >>>> >>>>> I understand you want to keep things as clean as possible, but are >>>>> we not going too far in our slimdown crusade? >>>> This is ridiculous, Jacques. This is not about the slimdown >>>> (crusade?), this ended up months ago. This is all about writing and >>>> maintaining good, well-crafted artifacts and code. The current OFBiz >>>> trunk is still a great mess and I am surprised (and a bit concerned) >>>> that you think we are going too far in the attempt to keep things >>>> clean. >>> What I mean is I don't see how and why (re-)adding error.log in >>> log4j2.xml will make it messy, really are we not splitting hairs here? >>> If you told me, "this will slow down and the system" or something >>> like that I could understand. But I explained why it should not, >>> except if you have an extremely big issue and then this big issue >>> would be your concern, not the error.log which would only be the >>> symptom. >>> >>>> Jacopo >>>> >>>> >>>> >> >> |
Ok... Viewpoints are made clear.
But ask yourself this: - What is better for the community, leaving it in or leaving it out? Think of the default user, not of the exeption - How much will it affect performance when left in or out? In stead of opposing each other, find consensus for the good of the project and its community. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Tue, Sep 9, 2014 at 11:42 AM, Adrian Crum < [hidden email]> wrote: > Jacques, > > You still are not understanding what you are saying, and you are not > understanding our replies. > > You are saying: > > 1. You want to change log settings because it benefits Jacques. > 2. You want to change ignore settings because it benefits Jacques. > > Jacopo and I are saying: > > 1. Every developer wants different log settings, so they are free to > modify them on their local copy. > 2. Every developer uses different tools and shortcuts, so they are free to > add them to their local copy. > 3. Since every developer is different, we should leave #1 and #2 out of > the trunk. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 9/9/2014 10:09 AM, Jacques Le Roux wrote: > >> My answer was >> >What I mean is I don't see how and why (re-)adding error.log in >> log4j2.xml will make it messy >> >> I just added a point about performance issue because I knew it would be >> the next argument on the table. Adding few lines in log4j2.xml does not >> stand as an argument to me. >> >> Jacques >> >> Le 09/09/2014 10:55, Jacopo Cappellato a écrit : >> >>> Jacques, >>> >>> you are clearly not reading what I and others wrote. >>> >>> Jacopo >>> >>> On Sep 9, 2014, at 10:39 AM, Jacques Le Roux >>> <[hidden email]> wrote: >>> >>> Le 09/09/2014 10:12, Jacopo Cappellato a écrit : >>>> >>>>> On Sep 9, 2014, at 9:52 AM, Jacques Le Roux >>>>> <[hidden email]> wrote: >>>>> >>>>> I understand you want to keep things as clean as possible, but are >>>>>> we not going too far in our slimdown crusade? >>>>>> >>>>> This is ridiculous, Jacques. This is not about the slimdown >>>>> (crusade?), this ended up months ago. This is all about writing and >>>>> maintaining good, well-crafted artifacts and code. The current OFBiz >>>>> trunk is still a great mess and I am surprised (and a bit concerned) >>>>> that you think we are going too far in the attempt to keep things >>>>> clean. >>>>> >>>> What I mean is I don't see how and why (re-)adding error.log in >>>> log4j2.xml will make it messy, really are we not splitting hairs here? >>>> If you told me, "this will slow down and the system" or something >>>> like that I could understand. But I explained why it should not, >>>> except if you have an extremely big issue and then this big issue >>>> would be your concern, not the error.log which would only be the >>>> symptom. >>>> >>>> Jacopo >>>>> >>>>> >>>>> >>>>> >>> >>> |
On Sep 9, 2014, at 12:24 PM, Pierre Smits <[hidden email]> wrote:
> In stead of opposing each other, find consensus for the good of the project > and its community. This is the main reason the trunk should be kept as clean as possible, instead of changing stuff to fit committers' personal preferences. Jacopo |
Free forum by Nabble | Edit this page |