Where is the error.log gone?
Locked
12345
12345
Re: Where is the error.log gone?
 
|
> 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. Regards Scott On 12/09/2014, at 8:35 pm, Jacques Le Roux <[hidden email]> wrote: > > Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 >> >> |
Re: Where is the error.log gone?
|
|
In reply to this post by Pierre Smits
On what basis?
Regards Scott On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> wrote: > I support reverting this regression. > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < > [hidden email]> wrote: > >> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >> [hidden email]> wrote: >> >>> I don't understand why you are so not open to put back the error.log in >> log4j2.xml >> >> Because it is just one of 1 million possible ways to configure logging: it >> is a specific one on not a generic one and so it is not better than the >> other 1 million possibilities; you have explained why you like it but me or >> others could find similar arguments for the other millions ways; since no >> one seconded you in your attempt to add the configuration back this >> confirms to me that this specific configuration is not better than other; >> for this reason it should be left out of the trunk. >> >>> and qualify this as a mess and almost myself and idiot. >> >> I didn't say this and the mail archive can demonstrate it; you have been >> trying to raise the tone of the conversation since the beginning of this >> thread (and you did the same in at least another thread recently) but I >> will not start to fight with you. >> >> Jacopo >> >> |
Re: Where is the error.log gone?
Administrator
|
In reply to this post by Scott Gray-2
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 <[hidden email]> wrote: > >> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 >>> > > |
Re: Where is the error.log gone?
|
|
In reply to this post by Scott Gray-2
On the basis that log analysis and error identification/reporting costs
money, and the more complex this process is the more it costs. An error log contains less clutter and is the first point in identification and triage of (severe) issues in any organisation that has adopted a methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), specifically the error control process (in ITIL) Without this OOTB more time is spend on: - going through the other, more detailed log(s) in the various OFBiz systems an organisation might have (e.g. dev, test, prod, etc) - getting the error log back and ensuring that it stays in. 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 2:29 AM, Scott Gray <[hidden email]> wrote: > On what basis? > > Regards > Scott > > On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> wrote: > > > I support reverting this regression. > > > > Pierre Smits > > > > *ORRTIZ.COM <http://www.orrtiz.com>* > > Services & Solutions for Cloud- > > Based Manufacturing, Professional > > Services and Retail & Trade > > http://www.orrtiz.com > > > > On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < > > [hidden email]> wrote: > > > >> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < > >> [hidden email]> wrote: > >> > >>> I don't understand why you are so not open to put back the error.log in > >> log4j2.xml > >> > >> Because it is just one of 1 million possible ways to configure logging: > it > >> is a specific one on not a generic one and so it is not better than the > >> other 1 million possibilities; you have explained why you like it but > me or > >> others could find similar arguments for the other millions ways; since > no > >> one seconded you in your attempt to add the configuration back this > >> confirms to me that this specific configuration is not better than > other; > >> for this reason it should be left out of the trunk. > >> > >>> and qualify this as a mess and almost myself and idiot. > >> > >> I didn't say this and the mail archive can demonstrate it; you have been > >> trying to raise the tone of the conversation since the beginning of this > >> thread (and you did the same in at least another thread recently) but I > >> will not start to fight with you. > >> > >> Jacopo > >> > >> > > |
Re: Where is the error.log gone?
|
|
In reply to this post by Jacques Le Roux
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 <[hidden email]> 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 <[hidden email]> wrote: >> >>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 >>>> >> >> > |
Re: Where is the error.log gone?
|
|
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 <[hidden email]> 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 <[hidden email]> > 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 < > [hidden email]> wrote: > >> > >>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : > >>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux < > [hidden email]> 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 < > [hidden email]> 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 > >>>> > >> > >> > > > > |
Re: Where is the error.log gone?
|
|
How so?
Regards Scott On 15/09/2014, at 8:42 pm, Pierre Smits <[hidden email]> 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 <[hidden email]> > 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 <[hidden email]> >> 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 < >> [hidden email]> wrote: >>>> >>>>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux < >> [hidden email]> 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 < >> [hidden email]> 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 >>>>>> >>>> >>>> >>> >> >> |
Re: Where is the error.log gone?
|
|
In reply to this post by Pierre Smits
As someone who has spent thousands of hours debugging OFBiz installations I can assure you that the error.log is redundant and provides no true value over ofbiz.log. As I've mentioned a few times now, OFBiz errors are regularly worthless without knowledge of the context of the error which can only be found in ofbiz.log.
With a few command line tools "clutter" is a total non-issue and even a basic knowledge of those tools is a total time saver when investigating log files. Regards Scott On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: > On the basis that log analysis and error identification/reporting costs > money, and the more complex this process is the more it costs. > An error log contains less clutter and is the first point in identification > and triage of (severe) issues in any organisation that has adopted a > methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), > specifically the error control process (in ITIL) > > Without this OOTB more time is spend on: > > - going through the other, more detailed log(s) in the various OFBiz > systems an organisation might have (e.g. dev, test, prod, etc) > - getting the error log back and ensuring that it stays in. > > > > 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 2:29 AM, Scott Gray <[hidden email]> > wrote: > >> On what basis? >> >> Regards >> Scott >> >> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> wrote: >> >>> I support reverting this regression. >>> >>> Pierre Smits >>> >>> *ORRTIZ.COM <http://www.orrtiz.com>* >>> Services & Solutions for Cloud- >>> Based Manufacturing, Professional >>> Services and Retail & Trade >>> http://www.orrtiz.com >>> >>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>> [hidden email]> wrote: >>> >>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>> [hidden email]> wrote: >>>> >>>>> I don't understand why you are so not open to put back the error.log in >>>> log4j2.xml >>>> >>>> Because it is just one of 1 million possible ways to configure logging: >> it >>>> is a specific one on not a generic one and so it is not better than the >>>> other 1 million possibilities; you have explained why you like it but >> me or >>>> others could find similar arguments for the other millions ways; since >> no >>>> one seconded you in your attempt to add the configuration back this >>>> confirms to me that this specific configuration is not better than >> other; >>>> for this reason it should be left out of the trunk. >>>> >>>>> and qualify this as a mess and almost myself and idiot. >>>> >>>> I didn't say this and the mail archive can demonstrate it; you have been >>>> trying to raise the tone of the conversation since the beginning of this >>>> thread (and you did the same in at least another thread recently) but I >>>> will not start to fight with you. >>>> >>>> Jacopo >>>> >>>> >> >> |
Re: Where is the error.log gone?
|
|
In reply to this post by Scott Gray-2
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 <[hidden email]> wrote: > How so? > > Regards > Scott > > On 15/09/2014, at 8:42 pm, Pierre Smits <[hidden email]> 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 <[hidden email] > > > > 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 < > [hidden email]> > >> 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 < > >> [hidden email]> wrote: > >>>> > >>>>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : > >>>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux < > >> [hidden email]> 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 < > >> [hidden email]> 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 > >>>>>> > >>>> > >>>> > >>> > >> > >> > > |
Re: Where is the error.log gone?
|
Administrator
|
In reply to this post by Scott Gray-2
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 <[hidden email]> 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 <[hidden email]> wrote: >>> >>>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 >>> > > |
Re: Where is the error.log gone?
|
Administrator
|
In reply to this post by Scott Gray-2
Not when you want to quickly spot obvious errors that you can easily fix or wait to fix later, and yes I spent my share of debugging also...
But anyway, why do you want to *force* everybody to use the same way than you, are you an OFBiz prophet? Jacques Le 15/09/2014 10:53, Scott Gray a écrit : > As someone who has spent thousands of hours debugging OFBiz installations I can assure you that the error.log is redundant and provides no true value over ofbiz.log. As I've mentioned a few times now, OFBiz errors are regularly worthless without knowledge of the context of the error which can only be found in ofbiz.log. > > With a few command line tools "clutter" is a total non-issue and even a basic knowledge of those tools is a total time saver when investigating log files. > > Regards > Scott > > On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: > >> On the basis that log analysis and error identification/reporting costs >> money, and the more complex this process is the more it costs. >> An error log contains less clutter and is the first point in identification >> and triage of (severe) issues in any organisation that has adopted a >> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), >> specifically the error control process (in ITIL) >> >> Without this OOTB more time is spend on: >> >> - going through the other, more detailed log(s) in the various OFBiz >> systems an organisation might have (e.g. dev, test, prod, etc) >> - getting the error log back and ensuring that it stays in. >> >> >> >> 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 2:29 AM, Scott Gray <[hidden email]> >> wrote: >> >>> On what basis? >>> >>> Regards >>> Scott >>> >>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> wrote: >>> >>>> I support reverting this regression. >>>> >>>> Pierre Smits >>>> >>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>> Services & Solutions for Cloud- >>>> Based Manufacturing, Professional >>>> Services and Retail & Trade >>>> http://www.orrtiz.com >>>> >>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>>> [hidden email]> wrote: >>>> >>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>>> [hidden email]> wrote: >>>>> >>>>>> I don't understand why you are so not open to put back the error.log in >>>>> log4j2.xml >>>>> >>>>> Because it is just one of 1 million possible ways to configure logging: >>> it >>>>> is a specific one on not a generic one and so it is not better than the >>>>> other 1 million possibilities; you have explained why you like it but >>> me or >>>>> others could find similar arguments for the other millions ways; since >>> no >>>>> one seconded you in your attempt to add the configuration back this >>>>> confirms to me that this specific configuration is not better than >>> other; >>>>> for this reason it should be left out of the trunk. >>>>> >>>>>> and qualify this as a mess and almost myself and idiot. >>>>> I didn't say this and the mail archive can demonstrate it; you have been >>>>> trying to raise the tone of the conversation since the beginning of this >>>>> thread (and you did the same in at least another thread recently) but I >>>>> will not start to fight with you. >>>>> >>>>> Jacopo >>>>> >>>>> >>> > > |
Re: Where is the error.log gone?
|
|
In reply to this post by Jacques Le Roux
Not only that, but many of the larger organisations I have worked for had
automated processes in place that emailed the daily error logs to specific officers, so that not only first level sys admins had that information. And this had all to do with certifications, CRG, etc. And cost of operations of course. 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 11:16 AM, Jacques Le Roux < [hidden email]> 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 <[hidden email]> >> 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 < >>>> [hidden email]> wrote: >>>> >>>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>>>> >>>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux < >>>>>> [hidden email]> 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 < >>>>>>>>> [hidden email]> 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 >>>>>>>>> >>>>>>>> >>>> >> >> > |
Re: Where is the error.log gone?
|
|
In reply to this post by Jacques Le Roux
I'm not trying to force anything, I didn't make the change. I'm just stating my opinion in this debate the same as you or anyone else. Even the change is not about forcing anyone into a specific workflow, the debate is about making sensible defaults for OFBiz. Changes can be made to suit anyone's needs in their respective checkouts.
Regards Scott On 15/09/2014, at 9:19 pm, Jacques Le Roux <[hidden email]> wrote: > Not when you want to quickly spot obvious errors that you can easily fix or wait to fix later, and yes I spent my share of debugging also... > > But anyway, why do you want to *force* everybody to use the same way than you, are you an OFBiz prophet? > > Jacques > > Le 15/09/2014 10:53, Scott Gray a écrit : >> As someone who has spent thousands of hours debugging OFBiz installations I can assure you that the error.log is redundant and provides no true value over ofbiz.log. As I've mentioned a few times now, OFBiz errors are regularly worthless without knowledge of the context of the error which can only be found in ofbiz.log. >> >> With a few command line tools "clutter" is a total non-issue and even a basic knowledge of those tools is a total time saver when investigating log files. >> >> Regards >> Scott >> >> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: >> >>> On the basis that log analysis and error identification/reporting costs >>> money, and the more complex this process is the more it costs. >>> An error log contains less clutter and is the first point in identification >>> and triage of (severe) issues in any organisation that has adopted a >>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), >>> specifically the error control process (in ITIL) >>> >>> Without this OOTB more time is spend on: >>> >>> - going through the other, more detailed log(s) in the various OFBiz >>> systems an organisation might have (e.g. dev, test, prod, etc) >>> - getting the error log back and ensuring that it stays in. >>> >>> >>> >>> 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 2:29 AM, Scott Gray <[hidden email]> >>> wrote: >>> >>>> On what basis? >>>> >>>> Regards >>>> Scott >>>> >>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> wrote: >>>> >>>>> I support reverting this regression. >>>>> >>>>> Pierre Smits >>>>> >>>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>>> Services & Solutions for Cloud- >>>>> Based Manufacturing, Professional >>>>> Services and Retail & Trade >>>>> http://www.orrtiz.com >>>>> >>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>>>> [hidden email]> wrote: >>>>> >>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>>>> [hidden email]> wrote: >>>>>> >>>>>>> I don't understand why you are so not open to put back the error.log in >>>>>> log4j2.xml >>>>>> >>>>>> Because it is just one of 1 million possible ways to configure logging: >>>> it >>>>>> is a specific one on not a generic one and so it is not better than the >>>>>> other 1 million possibilities; you have explained why you like it but >>>> me or >>>>>> others could find similar arguments for the other millions ways; since >>>> no >>>>>> one seconded you in your attempt to add the configuration back this >>>>>> confirms to me that this specific configuration is not better than >>>> other; >>>>>> for this reason it should be left out of the trunk. >>>>>> >>>>>>> and qualify this as a mess and almost myself and idiot. >>>>>> I didn't say this and the mail archive can demonstrate it; you have been >>>>>> trying to raise the tone of the conversation since the beginning of this >>>>>> thread (and you did the same in at least another thread recently) but I >>>>>> will not start to fight with you. >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>> >> >> > |
Re: Where is the error.log gone?
|
|
This is not just about the fact that changes can be made by anybody in
their own implementations. This is also a message to all prospective users of OFBiz, and to the organisations who are trying to sell OFBiz as a solution to their prospective customers. 'OFBiz doesn't have an error log OOTB' is a stupid message to convey to those parties. 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 11:27 AM, Scott Gray <[hidden email]> wrote: > I'm not trying to force anything, I didn't make the change. I'm just > stating my opinion in this debate the same as you or anyone else. Even the > change is not about forcing anyone into a specific workflow, the debate is > about making sensible defaults for OFBiz. Changes can be made to suit > anyone's needs in their respective checkouts. > > Regards > Scott > > On 15/09/2014, at 9:19 pm, Jacques Le Roux <[hidden email]> > wrote: > > > Not when you want to quickly spot obvious errors that you can easily fix > or wait to fix later, and yes I spent my share of debugging also... > > > > But anyway, why do you want to *force* everybody to use the same way > than you, are you an OFBiz prophet? > > > > Jacques > > > > Le 15/09/2014 10:53, Scott Gray a écrit : > >> As someone who has spent thousands of hours debugging OFBiz > installations I can assure you that the error.log is redundant and provides > no true value over ofbiz.log. As I've mentioned a few times now, OFBiz > errors are regularly worthless without knowledge of the context of the > error which can only be found in ofbiz.log. > >> > >> With a few command line tools "clutter" is a total non-issue and even a > basic knowledge of those tools is a total time saver when investigating log > files. > >> > >> Regards > >> Scott > >> > >> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: > >> > >>> On the basis that log analysis and error identification/reporting costs > >>> money, and the more complex this process is the more it costs. > >>> An error log contains less clutter and is the first point in > identification > >>> and triage of (severe) issues in any organisation that has adopted a > >>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), > >>> specifically the error control process (in ITIL) > >>> > >>> Without this OOTB more time is spend on: > >>> > >>> - going through the other, more detailed log(s) in the various OFBiz > >>> systems an organisation might have (e.g. dev, test, prod, etc) > >>> - getting the error log back and ensuring that it stays in. > >>> > >>> > >>> > >>> 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 2:29 AM, Scott Gray < > [hidden email]> > >>> wrote: > >>> > >>>> On what basis? > >>>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> > wrote: > >>>> > >>>>> I support reverting this regression. > >>>>> > >>>>> Pierre Smits > >>>>> > >>>>> *ORRTIZ.COM <http://www.orrtiz.com>* > >>>>> Services & Solutions for Cloud- > >>>>> Based Manufacturing, Professional > >>>>> Services and Retail & Trade > >>>>> http://www.orrtiz.com > >>>>> > >>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < > >>>>> [hidden email]> wrote: > >>>>> > >>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < > >>>>>> [hidden email]> wrote: > >>>>>> > >>>>>>> I don't understand why you are so not open to put back the > error.log in > >>>>>> log4j2.xml > >>>>>> > >>>>>> Because it is just one of 1 million possible ways to configure > logging: > >>>> it > >>>>>> is a specific one on not a generic one and so it is not better than > the > >>>>>> other 1 million possibilities; you have explained why you like it > but > >>>> me or > >>>>>> others could find similar arguments for the other millions ways; > since > >>>> no > >>>>>> one seconded you in your attempt to add the configuration back this > >>>>>> confirms to me that this specific configuration is not better than > >>>> other; > >>>>>> for this reason it should be left out of the trunk. > >>>>>> > >>>>>>> and qualify this as a mess and almost myself and idiot. > >>>>>> I didn't say this and the mail archive can demonstrate it; you have > been > >>>>>> trying to raise the tone of the conversation since the beginning of > this > >>>>>> thread (and you did the same in at least another thread recently) > but I > >>>>>> will not start to fight with you. > >>>>>> > >>>>>> Jacopo > >>>>>> > >>>>>> > >>>> > >> > >> > > > > |
Re: Where is the error.log gone?
|
|
In reply to this post by Jacques Le Roux
Jacques,
That perspective goes both ways. From my perspective, you are trying *force* everyone to do things your way. That is why everyone is trying to get you to realize that a one-size-fits-all setting will not work - because everyone is different. If you want the error log on your installation, then configure it to do so. Why *force* EVERYONE to have an error log? Adrian Crum Sandglass Software www.sandglass-software.com On 9/15/2014 10:19 AM, Jacques Le Roux wrote: > Not when you want to quickly spot obvious errors that you can easily fix > or wait to fix later, and yes I spent my share of debugging also... > > But anyway, why do you want to *force* everybody to use the same way > than you, are you an OFBiz prophet? > > Jacques > > Le 15/09/2014 10:53, Scott Gray a écrit : >> As someone who has spent thousands of hours debugging OFBiz >> installations I can assure you that the error.log is redundant and >> provides no true value over ofbiz.log. As I've mentioned a few times >> now, OFBiz errors are regularly worthless without knowledge of the >> context of the error which can only be found in ofbiz.log. >> >> With a few command line tools "clutter" is a total non-issue and even >> a basic knowledge of those tools is a total time saver when >> investigating log files. >> >> Regards >> Scott >> >> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: >> >>> On the basis that log analysis and error identification/reporting costs >>> money, and the more complex this process is the more it costs. >>> An error log contains less clutter and is the first point in >>> identification >>> and triage of (severe) issues in any organisation that has adopted a >>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), >>> specifically the error control process (in ITIL) >>> >>> Without this OOTB more time is spend on: >>> >>> - going through the other, more detailed log(s) in the various OFBiz >>> systems an organisation might have (e.g. dev, test, prod, etc) >>> - getting the error log back and ensuring that it stays in. >>> >>> >>> >>> 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 2:29 AM, Scott Gray <[hidden email]> >>> wrote: >>> >>>> On what basis? >>>> >>>> Regards >>>> Scott >>>> >>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> wrote: >>>> >>>>> I support reverting this regression. >>>>> >>>>> Pierre Smits >>>>> >>>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>>> Services & Solutions for Cloud- >>>>> Based Manufacturing, Professional >>>>> Services and Retail & Trade >>>>> http://www.orrtiz.com >>>>> >>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>>>> [hidden email]> wrote: >>>>> >>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>>>> [hidden email]> wrote: >>>>>> >>>>>>> I don't understand why you are so not open to put back the >>>>>>> error.log in >>>>>> log4j2.xml >>>>>> >>>>>> Because it is just one of 1 million possible ways to configure >>>>>> logging: >>>> it >>>>>> is a specific one on not a generic one and so it is not better >>>>>> than the >>>>>> other 1 million possibilities; you have explained why you like it but >>>> me or >>>>>> others could find similar arguments for the other millions ways; >>>>>> since >>>> no >>>>>> one seconded you in your attempt to add the configuration back this >>>>>> confirms to me that this specific configuration is not better than >>>> other; >>>>>> for this reason it should be left out of the trunk. >>>>>> >>>>>>> and qualify this as a mess and almost myself and idiot. >>>>>> I didn't say this and the mail archive can demonstrate it; you >>>>>> have been >>>>>> trying to raise the tone of the conversation since the beginning >>>>>> of this >>>>>> thread (and you did the same in at least another thread recently) >>>>>> but I >>>>>> will not start to fight with you. >>>>>> >>>>>> Jacopo >>>>>> >>>>>> >>>> >> >> > |
Re: Where is the error.log gone?
|
|
In reply to this post by Jacques Le Roux
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>>> Le 12/09/2014 06:17, Jacopo Cappellato a écrit : >>>>>> On Sep 11, 2014, at 9:40 PM, Jacques Le Roux <[hidden email]> 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 <[hidden email]> 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 >>>> >> >> > |
Re: Where is the error.log gone?
|
|
In reply to this post by Adrian Crum-3
Why *force* EVERYONE not to have an error log OOTB? Why *force* EVERYONE to
spend time and money to get it back in? 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 12:09 PM, Adrian Crum < [hidden email]> wrote: > Jacques, > > That perspective goes both ways. From my perspective, you are trying > *force* everyone to do things your way. > > That is why everyone is trying to get you to realize that a > one-size-fits-all setting will not work - because everyone is different. > > If you want the error log on your installation, then configure it to do > so. Why *force* EVERYONE to have an error log? > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 9/15/2014 10:19 AM, Jacques Le Roux wrote: > >> Not when you want to quickly spot obvious errors that you can easily fix >> or wait to fix later, and yes I spent my share of debugging also... >> >> But anyway, why do you want to *force* everybody to use the same way >> than you, are you an OFBiz prophet? >> >> Jacques >> >> Le 15/09/2014 10:53, Scott Gray a écrit : >> >>> As someone who has spent thousands of hours debugging OFBiz >>> installations I can assure you that the error.log is redundant and >>> provides no true value over ofbiz.log. As I've mentioned a few times >>> now, OFBiz errors are regularly worthless without knowledge of the >>> context of the error which can only be found in ofbiz.log. >>> >>> With a few command line tools "clutter" is a total non-issue and even >>> a basic knowledge of those tools is a total time saver when >>> investigating log files. >>> >>> Regards >>> Scott >>> >>> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: >>> >>> On the basis that log analysis and error identification/reporting costs >>>> money, and the more complex this process is the more it costs. >>>> An error log contains less clutter and is the first point in >>>> identification >>>> and triage of (severe) issues in any organisation that has adopted a >>>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), >>>> specifically the error control process (in ITIL) >>>> >>>> Without this OOTB more time is spend on: >>>> >>>> - going through the other, more detailed log(s) in the various OFBiz >>>> systems an organisation might have (e.g. dev, test, prod, etc) >>>> - getting the error log back and ensuring that it stays in. >>>> >>>> >>>> >>>> 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 2:29 AM, Scott Gray <[hidden email] >>>> > >>>> wrote: >>>> >>>> On what basis? >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> >>>>> wrote: >>>>> >>>>> I support reverting this regression. >>>>>> >>>>>> Pierre Smits >>>>>> >>>>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>>>> Services & Solutions for Cloud- >>>>>> Based Manufacturing, Professional >>>>>> Services and Retail & Trade >>>>>> http://www.orrtiz.com >>>>>> >>>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>>>>> [hidden email]> wrote: >>>>>> >>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> I don't understand why you are so not open to put back the >>>>>>>> error.log in >>>>>>>> >>>>>>> log4j2.xml >>>>>>> >>>>>>> Because it is just one of 1 million possible ways to configure >>>>>>> logging: >>>>>>> >>>>>> it >>>>> >>>>>> is a specific one on not a generic one and so it is not better >>>>>>> than the >>>>>>> other 1 million possibilities; you have explained why you like it but >>>>>>> >>>>>> me or >>>>> >>>>>> others could find similar arguments for the other millions ways; >>>>>>> since >>>>>>> >>>>>> no >>>>> >>>>>> one seconded you in your attempt to add the configuration back this >>>>>>> confirms to me that this specific configuration is not better than >>>>>>> >>>>>> other; >>>>> >>>>>> for this reason it should be left out of the trunk. >>>>>>> >>>>>>> and qualify this as a mess and almost myself and idiot. >>>>>>>> >>>>>>> I didn't say this and the mail archive can demonstrate it; you >>>>>>> have been >>>>>>> trying to raise the tone of the conversation since the beginning >>>>>>> of this >>>>>>> thread (and you did the same in at least another thread recently) >>>>>>> but I >>>>>>> will not start to fight with you. >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> >>>>>>> >>>>> >>> >>> >> |
Re: Where is the error.log gone?
|
|
No one is being forced to configure their deployment - it is a process
(and cost) associated with EVERY OFBiz installation, regardless of the outcome of this discussion. Adrian Crum Sandglass Software www.sandglass-software.com On 9/15/2014 11:14 AM, Pierre Smits wrote: > Why *force* EVERYONE not to have an error log OOTB? Why *force* EVERYONE to > spend time and money to get it back in? > > 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 12:09 PM, Adrian Crum < > [hidden email]> wrote: > >> Jacques, >> >> That perspective goes both ways. From my perspective, you are trying >> *force* everyone to do things your way. >> >> That is why everyone is trying to get you to realize that a >> one-size-fits-all setting will not work - because everyone is different. >> >> If you want the error log on your installation, then configure it to do >> so. Why *force* EVERYONE to have an error log? >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 9/15/2014 10:19 AM, Jacques Le Roux wrote: >> >>> Not when you want to quickly spot obvious errors that you can easily fix >>> or wait to fix later, and yes I spent my share of debugging also... >>> >>> But anyway, why do you want to *force* everybody to use the same way >>> than you, are you an OFBiz prophet? >>> >>> Jacques >>> >>> Le 15/09/2014 10:53, Scott Gray a écrit : >>> >>>> As someone who has spent thousands of hours debugging OFBiz >>>> installations I can assure you that the error.log is redundant and >>>> provides no true value over ofbiz.log. As I've mentioned a few times >>>> now, OFBiz errors are regularly worthless without knowledge of the >>>> context of the error which can only be found in ofbiz.log. >>>> >>>> With a few command line tools "clutter" is a total non-issue and even >>>> a basic knowledge of those tools is a total time saver when >>>> investigating log files. >>>> >>>> Regards >>>> Scott >>>> >>>> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: >>>> >>>> On the basis that log analysis and error identification/reporting costs >>>>> money, and the more complex this process is the more it costs. >>>>> An error log contains less clutter and is the first point in >>>>> identification >>>>> and triage of (severe) issues in any organisation that has adopted a >>>>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), >>>>> specifically the error control process (in ITIL) >>>>> >>>>> Without this OOTB more time is spend on: >>>>> >>>>> - going through the other, more detailed log(s) in the various OFBiz >>>>> systems an organisation might have (e.g. dev, test, prod, etc) >>>>> - getting the error log back and ensuring that it stays in. >>>>> >>>>> >>>>> >>>>> 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 2:29 AM, Scott Gray <[hidden email] >>>>>> >>>>> wrote: >>>>> >>>>> On what basis? >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> >>>>>> wrote: >>>>>> >>>>>> I support reverting this regression. >>>>>>> >>>>>>> Pierre Smits >>>>>>> >>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>>>>> Services & Solutions for Cloud- >>>>>>> Based Manufacturing, Professional >>>>>>> Services and Retail & Trade >>>>>>> http://www.orrtiz.com >>>>>>> >>>>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> I don't understand why you are so not open to put back the >>>>>>>>> error.log in >>>>>>>>> >>>>>>>> log4j2.xml >>>>>>>> >>>>>>>> Because it is just one of 1 million possible ways to configure >>>>>>>> logging: >>>>>>>> >>>>>>> it >>>>>> >>>>>>> is a specific one on not a generic one and so it is not better >>>>>>>> than the >>>>>>>> other 1 million possibilities; you have explained why you like it but >>>>>>>> >>>>>>> me or >>>>>> >>>>>>> others could find similar arguments for the other millions ways; >>>>>>>> since >>>>>>>> >>>>>>> no >>>>>> >>>>>>> one seconded you in your attempt to add the configuration back this >>>>>>>> confirms to me that this specific configuration is not better than >>>>>>>> >>>>>>> other; >>>>>> >>>>>>> for this reason it should be left out of the trunk. >>>>>>>> >>>>>>>> and qualify this as a mess and almost myself and idiot. >>>>>>>>> >>>>>>>> I didn't say this and the mail archive can demonstrate it; you >>>>>>>> have been >>>>>>>> trying to raise the tone of the conversation since the beginning >>>>>>>> of this >>>>>>>> thread (and you did the same in at least another thread recently) >>>>>>>> but I >>>>>>>> will not start to fight with you. >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >>> > |
Re: Where is the error.log gone?
|
|
In reply to this post by Pierre Smits
Everyone? So far we only have Jacques. Well and you I guess, but that's debatable considering you only just decided yesterday to form a strong opinion so I have my doubts about it having a negative impact for you.
Regards Scott On 15/09/2014, at 10:14 pm, Pierre Smits <[hidden email]> wrote: > Why *force* EVERYONE not to have an error log OOTB? Why *force* EVERYONE to > spend time and money to get it back in? > > 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 12:09 PM, Adrian Crum < > [hidden email]> wrote: > >> Jacques, >> >> That perspective goes both ways. From my perspective, you are trying >> *force* everyone to do things your way. >> >> That is why everyone is trying to get you to realize that a >> one-size-fits-all setting will not work - because everyone is different. >> >> If you want the error log on your installation, then configure it to do >> so. Why *force* EVERYONE to have an error log? >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 9/15/2014 10:19 AM, Jacques Le Roux wrote: >> >>> Not when you want to quickly spot obvious errors that you can easily fix >>> or wait to fix later, and yes I spent my share of debugging also... >>> >>> But anyway, why do you want to *force* everybody to use the same way >>> than you, are you an OFBiz prophet? >>> >>> Jacques >>> >>> Le 15/09/2014 10:53, Scott Gray a écrit : >>> >>>> As someone who has spent thousands of hours debugging OFBiz >>>> installations I can assure you that the error.log is redundant and >>>> provides no true value over ofbiz.log. As I've mentioned a few times >>>> now, OFBiz errors are regularly worthless without knowledge of the >>>> context of the error which can only be found in ofbiz.log. >>>> >>>> With a few command line tools "clutter" is a total non-issue and even >>>> a basic knowledge of those tools is a total time saver when >>>> investigating log files. >>>> >>>> Regards >>>> Scott >>>> >>>> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> wrote: >>>> >>>> On the basis that log analysis and error identification/reporting costs >>>>> money, and the more complex this process is the more it costs. >>>>> An error log contains less clutter and is the first point in >>>>> identification >>>>> and triage of (severe) issues in any organisation that has adopted a >>>>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), >>>>> specifically the error control process (in ITIL) >>>>> >>>>> Without this OOTB more time is spend on: >>>>> >>>>> - going through the other, more detailed log(s) in the various OFBiz >>>>> systems an organisation might have (e.g. dev, test, prod, etc) >>>>> - getting the error log back and ensuring that it stays in. >>>>> >>>>> >>>>> >>>>> 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 2:29 AM, Scott Gray <[hidden email] >>>>>> >>>>> wrote: >>>>> >>>>> On what basis? >>>>>> >>>>>> Regards >>>>>> Scott >>>>>> >>>>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> >>>>>> wrote: >>>>>> >>>>>> I support reverting this regression. >>>>>>> >>>>>>> Pierre Smits >>>>>>> >>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>* >>>>>>> Services & Solutions for Cloud- >>>>>>> Based Manufacturing, Professional >>>>>>> Services and Retail & Trade >>>>>>> http://www.orrtiz.com >>>>>>> >>>>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < >>>>>>> [hidden email]> wrote: >>>>>>> >>>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < >>>>>>>> [hidden email]> wrote: >>>>>>>> >>>>>>>> I don't understand why you are so not open to put back the >>>>>>>>> error.log in >>>>>>>>> >>>>>>>> log4j2.xml >>>>>>>> >>>>>>>> Because it is just one of 1 million possible ways to configure >>>>>>>> logging: >>>>>>>> >>>>>>> it >>>>>> >>>>>>> is a specific one on not a generic one and so it is not better >>>>>>>> than the >>>>>>>> other 1 million possibilities; you have explained why you like it but >>>>>>>> >>>>>>> me or >>>>>> >>>>>>> others could find similar arguments for the other millions ways; >>>>>>>> since >>>>>>>> >>>>>>> no >>>>>> >>>>>>> one seconded you in your attempt to add the configuration back this >>>>>>>> confirms to me that this specific configuration is not better than >>>>>>>> >>>>>>> other; >>>>>> >>>>>>> for this reason it should be left out of the trunk. >>>>>>>> >>>>>>>> and qualify this as a mess and almost myself and idiot. >>>>>>>>> >>>>>>>> I didn't say this and the mail archive can demonstrate it; you >>>>>>>> have been >>>>>>>> trying to raise the tone of the conversation since the beginning >>>>>>>> of this >>>>>>>> thread (and you did the same in at least another thread recently) >>>>>>>> but I >>>>>>>> will not start to fight with you. >>>>>>>> >>>>>>>> Jacopo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >>>> >>> |
Re: Where is the error.log gone?
|
|
Having an error.log OOTB, for sure, doens't have a negative impact on you.
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 12:19 PM, Scott Gray <[hidden email]> wrote: > Everyone? So far we only have Jacques. Well and you I guess, but that's > debatable considering you only just decided yesterday to form a strong > opinion so I have my doubts about it having a negative impact for you. > > Regards > Scott > > On 15/09/2014, at 10:14 pm, Pierre Smits <[hidden email]> wrote: > > > Why *force* EVERYONE not to have an error log OOTB? Why *force* EVERYONE > to > > spend time and money to get it back in? > > > > 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 12:09 PM, Adrian Crum < > > [hidden email]> wrote: > > > >> Jacques, > >> > >> That perspective goes both ways. From my perspective, you are trying > >> *force* everyone to do things your way. > >> > >> That is why everyone is trying to get you to realize that a > >> one-size-fits-all setting will not work - because everyone is different. > >> > >> If you want the error log on your installation, then configure it to do > >> so. Why *force* EVERYONE to have an error log? > >> > >> Adrian Crum > >> Sandglass Software > >> www.sandglass-software.com > >> > >> On 9/15/2014 10:19 AM, Jacques Le Roux wrote: > >> > >>> Not when you want to quickly spot obvious errors that you can easily > fix > >>> or wait to fix later, and yes I spent my share of debugging also... > >>> > >>> But anyway, why do you want to *force* everybody to use the same way > >>> than you, are you an OFBiz prophet? > >>> > >>> Jacques > >>> > >>> Le 15/09/2014 10:53, Scott Gray a écrit : > >>> > >>>> As someone who has spent thousands of hours debugging OFBiz > >>>> installations I can assure you that the error.log is redundant and > >>>> provides no true value over ofbiz.log. As I've mentioned a few times > >>>> now, OFBiz errors are regularly worthless without knowledge of the > >>>> context of the error which can only be found in ofbiz.log. > >>>> > >>>> With a few command line tools "clutter" is a total non-issue and even > >>>> a basic knowledge of those tools is a total time saver when > >>>> investigating log files. > >>>> > >>>> Regards > >>>> Scott > >>>> > >>>> On 15/09/2014, at 7:43 pm, Pierre Smits <[hidden email]> > wrote: > >>>> > >>>> On the basis that log analysis and error identification/reporting > costs > >>>>> money, and the more complex this process is the more it costs. > >>>>> An error log contains less clutter and is the first point in > >>>>> identification > >>>>> and triage of (severe) issues in any organisation that has adopted a > >>>>> methodology for service delivery (e.g. ITIL, ISO/IEC 20000, etc), > >>>>> specifically the error control process (in ITIL) > >>>>> > >>>>> Without this OOTB more time is spend on: > >>>>> > >>>>> - going through the other, more detailed log(s) in the various > OFBiz > >>>>> systems an organisation might have (e.g. dev, test, prod, etc) > >>>>> - getting the error log back and ensuring that it stays in. > >>>>> > >>>>> > >>>>> > >>>>> 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 2:29 AM, Scott Gray < > [hidden email] > >>>>>> > >>>>> wrote: > >>>>> > >>>>> On what basis? > >>>>>> > >>>>>> Regards > >>>>>> Scott > >>>>>> > >>>>>> On 12/09/2014, at 9:44 pm, Pierre Smits <[hidden email]> > >>>>>> wrote: > >>>>>> > >>>>>> I support reverting this regression. > >>>>>>> > >>>>>>> Pierre Smits > >>>>>>> > >>>>>>> *ORRTIZ.COM <http://www.orrtiz.com>* > >>>>>>> Services & Solutions for Cloud- > >>>>>>> Based Manufacturing, Professional > >>>>>>> Services and Retail & Trade > >>>>>>> http://www.orrtiz.com > >>>>>>> > >>>>>>> On Fri, Sep 12, 2014 at 11:29 AM, Jacopo Cappellato < > >>>>>>> [hidden email]> wrote: > >>>>>>> > >>>>>>> On Sep 12, 2014, at 10:35 AM, Jacques Le Roux < > >>>>>>>> [hidden email]> wrote: > >>>>>>>> > >>>>>>>> I don't understand why you are so not open to put back the > >>>>>>>>> error.log in > >>>>>>>>> > >>>>>>>> log4j2.xml > >>>>>>>> > >>>>>>>> Because it is just one of 1 million possible ways to configure > >>>>>>>> logging: > >>>>>>>> > >>>>>>> it > >>>>>> > >>>>>>> is a specific one on not a generic one and so it is not better > >>>>>>>> than the > >>>>>>>> other 1 million possibilities; you have explained why you like it > but > >>>>>>>> > >>>>>>> me or > >>>>>> > >>>>>>> others could find similar arguments for the other millions ways; > >>>>>>>> since > >>>>>>>> > >>>>>>> no > >>>>>> > >>>>>>> one seconded you in your attempt to add the configuration back this > >>>>>>>> confirms to me that this specific configuration is not better than > >>>>>>>> > >>>>>>> other; > >>>>>> > >>>>>>> for this reason it should be left out of the trunk. > >>>>>>>> > >>>>>>>> and qualify this as a mess and almost myself and idiot. > >>>>>>>>> > >>>>>>>> I didn't say this and the mail archive can demonstrate it; you > >>>>>>>> have been > >>>>>>>> trying to raise the tone of the conversation since the beginning > >>>>>>>> of this > >>>>>>>> thread (and you did the same in at least another thread recently) > >>>>>>>> but I > >>>>>>>> will not start to fight with you. > >>>>>>>> > >>>>>>>> Jacopo > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>>> > >>> > > |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |