Similar like not having a balance sheet and income statement in an accounting statement and putting it of with 'you can use a grep-equivalent' to retrieve the information on the financial health of the organisation to report to the stakeholders.
An automated process to generate an error.log file has a better tco than having an operator grep it daily from an other, more extensive log file to report on errors. Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Mon, Sep 15, 2014 at 10:50 AM, Scott Gray <[email protected]> wrote: > How so? > > Regards > Scott > > On 15/09/2014, at 8:42 pm, Pierre Smits <[email protected]> wrote: > > > Cost more time, more money... > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > > > On Mon, Sep 15, 2014 at 10:41 AM, Scott Gray <[email protected] > > > > wrote: > > > >> 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 > >>>>>> > >>>> > >>>> > >>> > >> > >> > >
