Le 09/09/2014 11:42, Adrian Crum a écrit :
Jacques,
You still are not understanding what you are saying, and you are not
understanding our replies.
Thanks for clearing my brain :D
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.
1) Seriously, *we had* the error.log before and I see no serious reasons and arguments in Jacopo's, Scott's and your answers to *remove it*. I find it
particularly handy when I want to quickly know the current issues (often minors) in a custom deployment. Without having to grep and such, just read a
short plain text file with all the errors collected in, no needs to look backward in zip files, etc.
2) Thank you for your permission of using my tools on my machine :)
Jacques
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
<[email protected]> wrote:
Le 09/09/2014 10:12, Jacopo Cappellato a écrit :
On Sep 9, 2014, at 9:52 AM, Jacques Le Roux
<[email protected]> 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
