ofbiz-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Gray <scott.g...@hotwaxmedia.com>
Subject Re: Where is the error.log gone?
Date Mon, 15 Sep 2014 10:13:27 GMT
I use ssh and terminal for all log research (until I need to dig deeply, in which case I download
the logs and split the them into individual threads, again because context is so important).
 When I need to monitor logs for errors connect via ssh and use tail + grep, after a deployment
for example.

I guess you have a different workflow, which is fine.  I'm just surprised that so much value
is placed in the error.log files since I personally find them to be almost useless and am
glad to have them out of the way.

Regards
Scott

On 15/09/2014, at 9:16 pm, Jacques Le Roux <jacques.le.roux@les7arts.com> wrote:

> We talk about lo4j2, you mean zgrep I guess?
> 
> Now consider this with no error.log
> You have to
> 1) login (how many machines?)
> 2) move to runtime/logs directory (idem)
> 3) moving/searching in your preferred text editor is easier than in a terminal. So at
this stage you might want to do rather "zgrep ":ERROR" ofbiz.log > error.log"
> 4) open error.log with your preferred text editor
> 5) reiterate when things change...
> 
> With error.log, if you have many machines you may have all the error.logs opened somewhere
(WinScp, SSH, you name it) and "it's a breeze" to update and search, etc.
> 
> I guess you see my points?
> 
> I really don't understand why Jacopo and yourself are so reluctant to put back the error.log
and I have to fight so much to explain my POV :/
> 
> Jacques
> 
> Le 15/09/2014 10:41, Scott Gray a écrit :
>> grep ":ERROR" ofbiz.log is too complicated?  It achieves exactly the same result.
>> 
>> Regards
>> Scott
>> 
>> On 15/09/2014, at 7:41 pm, Jacques Le Roux <jacques.le.roux@les7arts.com> wrote:
>> 
>>> 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.roux@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.roux@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.roux@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
>>>> 
>> 
>> 
> 


Mime
View raw message