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 >>>> >> >> >
