Mailing-List: contact dev-help@ofbiz.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ofbiz.apache.org
Received-SPF: pass (nike.apache.org: domain of scott.gray@hotwaxmedia.com
 designates 199.119.127.72 as permitted sender)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: Where is the error.log gone?
From: Scott Gray <scott.gray@hotwaxmedia.com>
In-Reply-To: <5416AE52.9000307@les7arts.com>
Date: Mon, 15 Sep 2014 22:13:27 +1200
Content-Transfer-Encoding: quoted-printable
Message-Id: <ABEE4C59-4BFA-4D1C-90E6-0819E1FAFAB6@hotwaxmedia.com>
References: <540D9D15.5020403@les7arts.com>
 <56E94A0E-E984-4226-92BE-B1746D589D4C@hotwaxmedia.com>
 <540E8B41.4060809@les7arts.com>
 <3B4BCDBE-B580-4ACB-B934-5F597B0FF622@hotwaxmedia.com>
 <540E9E9F.8080701@sandglass-software.com> <540EB1AA.9030301@les7arts.com>
 <67104CA2-EA71-4EE9-A9E8-A86182D04E31@hotwaxmedia.com>
 <540EBCAB.2030308@les7arts.com>
 <F268F707-1E0E-463B-A6FF-CD9E1B2F6BF6@hotwaxmedia.com>
 <540EC3AD.8090000@les7arts.com> <540ECB6D.50506@sandglass-software.com>
 <CADPkm87bu8_vxtADrXMmgLij9epEW4RsS189uq=VMJ0ZZewHYQ@mail.gmail.com>
 <EC62924B-8C85-433F-848E-DF5E0065A120@hotwaxmedia.com>
 <540EE3F5.6010403@librenberry.net> <540EF15C.2020004@les7arts.com>
 <8DC1EDD4-CE8B-4611-A597-E274D608CC9A@gmail.com>
 <5411FAC7.4030500@les7arts.com>
 <E2650414-5E97-49A5-93C8-B6C5F651A89F@hotwaxmedia.com>
 <5412B06E.5040706@les7arts.com>
 <8065A1E5-E000-43DF-98E2-423A8E8E783E@hotwaxmedia.com> <54169811.30505
 05@les7arts.com> <61B18D13-C9B5-4083-BCA8-C443E7E80BF9@hotwaxmedia.com>
 <5416AE52.9000
 307@les7arts.com>
To: dev@ofbiz.apache.org

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?
>=20
> 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...
>=20
> 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.
>=20
> I guess you see my points?
>=20
> 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 :/
>=20
> Jacques
>=20
> Le 15/09/2014 10:41, Scott Gray a =E9crit :
>> grep ":ERROR" ofbiz.log is too complicated?  It achieves exactly the =
same result.
>>=20
>> Regards
>> Scott
>>=20
>> On 15/09/2014, at 7:41 pm, Jacques Le Roux =
<jacques.le.roux@les7arts.com> wrote:
>>=20
>>> Le 15/09/2014 02:29, Scott Gray a =E9crit :
>>>>> 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.
>>>=20
>>> Thanks for asking
>>>=20
>>> Jacques
>>>=20
>>>> Regards
>>>> Scott
>>>>=20
>>>> On 12/09/2014, at 8:35 pm, Jacques Le Roux =
<jacques.le.roux@les7arts.com> wrote:
>>>>=20
>>>>> Le 12/09/2014 06:17, Jacopo Cappellato a =E9crit :
>>>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux =
<jacques.le.roux@les7arts.com> wrote:
>>>>>>=20
>>>>>>> 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
>>>>>>=20
>>>>>>> We could, as suggested Nicolas, add some educational comments in =
log4j2.xml and add 2 commented out sections for error.log
>>>>>>>=20
>>>>>> 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
>>>>>=20
>>>>> 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 :/
>>>>>=20
>>>>> 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?
>>>>>=20
>>>>> 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).
>>>>>=20
>>>>> Jacques
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>> Jacopo
>>>>>>=20
>>>>>>> Agreed?
>>>>>>>=20
>>>>>>> Jacques
>>>>>>>=20
>>>>>>> Le 09/09/2014 15:10, Pierre Smits a =E9crit :
>>>>>>>> And for whom
>>>>>>>>=20
>>>>>>>> Verstuurd vanaf mijn iPad
>>>>>>>>=20
>>>>>>>>> Op 9 sep. 2014 om 14:23 heeft Jacques Le Roux =
<jacques.le.roux@les7arts.com> het volgende geschreven:
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> Le 09/09/2014 13:26, Nicolas Malin a =E9crit :
>>>>>>>>>> Le 09/09/2014 12:41, Jacopo Cappellato a =E9crit :
>>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> No I don't use trunk for my configuration, I have my own =
parameters with my own method to deploy them :)
>>>>>>>>>>=20
>>>>>>>>>> Nicolas
>>>>>>>>>>=20
>>>>>>>>> That's a very interesting point Nicolas. The problem is now to =
know what means "as clean as possible" in Jacopo's sentence above
>>>>>>>>>=20
>>>>>>>>> Jacques
>>>>=20
>>=20
>>=20
>=20