Le 08/09/2014 23:31, Scott Gray a écrit :
On 9/09/2014, at 2:59 am, Jacopo Cappellato <jacopo.cappell...@gmail.com> wrote:

On Sep 8, 2014, at 3:51 PM, Jacques Le Roux <jacques.le.r...@les7arts.com> 
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



Reply via email to