Le 15/09/2014 02:29, Scott Gray a écrit :
If you want an example of its handy use, here is one. I want to monitor what's
happening in the trunk demo. Because it's a an efficient mean, beside tests and
reviews, to early spot new introduced errors.
Of course I can got there and run zgrep, but it's much easier to simply monitor
an error.log file. The same apply in custom project.
Could you please explain how it is easier? There are a lot of errors (I would
say the majority) where the single log line doesn't give you anywhere near
enough information to find out the source and cause. For those you ultimately
always have to go to the ofbiz.log file to understand the context of the error.
To early discriminate if it's an important (or very important) error/s that should be addressed ASAP. In other words to define priorities, notably
when in development step with a team.
Thanks for asking
Jacques
Regards
Scott
On 12/09/2014, at 8:35 pm, Jacques Le Roux <jacques.le.r...@les7arts.com> wrote:
Le 12/09/2014 06:17, Jacopo Cappellato a écrit :
On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <jacques.le.r...@les7arts.com>
wrote:
Since Jacopo did not answer, here is my proposition.
Was there a question for me? I was hoping that this waste of time was finished
We could, as suggested Nicolas, add some educational comments in log4j2.xml and
add 2 commented out sections for error.log
So, you are not happy until you mess up with the log4j2 config file? :-) Apart
from you, Jacques, no one complained or asked for modifications to the config
file (even after you asked for feedback).
I could be wrong, but it seems to me Pierre and Nicolas expressed something
about it
I'm not asking to put back the error.log w/o good reasons and I already
explained them
If you want an example of its handy use, here is one. I want to monitor what's
happening in the trunk demo. Because it's a an efficient mean, beside tests and
reviews, to early spot new introduced errors.
Of course I can got there and run zgrep, but it's much easier to simply monitor
an error.log file. The same apply in custom project.
Of course again, I can change the log4j2.xml there as I can schlep a patch in
all places I would have to in future :/
I don't understand why you are so not open to put back the error.log in
log4j2.xml and qualify this as a mess and almost myself and idiot. Could you
explain your reasons please?
For the other part (comments), I explained why I prefer to have comments in
files over having an online documentation, ever if of course having both is not
bad (as long as the online doc is updated).
Jacques
Jacopo
Agreed?
Jacques
Le 09/09/2014 15:10, Pierre Smits a écrit :
And for whom
Verstuurd vanaf mijn iPad
Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux <jacques.le.r...@les7arts.com>
het volgende geschreven:
Le 09/09/2014 13:26, Nicolas Malin a écrit :
Le 09/09/2014 12:41, Jacopo Cappellato a écrit :
This is the main reason the trunk should be kept as clean as possible, instead
of changing stuff to fit committers' personal preferences.
It's clear and good to simplify the configuration on production site.
On some other projet (mostly on debian ;) ), configuration file contains few
enable element but so mostly commented configurations with context explication
of the reason to use it.
With a good text editor (notepad no match) it's also clear and simple and help
uncover some other view.
No I don't use trunk for my configuration, I have my own parameters with my own
method to deploy them :)
Nicolas
That's a very interesting point Nicolas. The problem is now to know what means "as
clean as possible" in Jacopo's sentence above
Jacques
