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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >>>> wrote: >>>> >>>>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux >>>>>> <[email protected]> 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 >>>>>>>>> <[email protected]> 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 >>>> >> >> >
