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