[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: Log class problems
Also think about the real purpose of these classes.
In CPPSERV there will be method in ServletContext class
Something along the lines of CLogger& getLogger();
And user will want to do
getContext().getLogger()<<warning<<"Moo"<<std::endl;
If priority/facility make no sense for common Logger then above is invalid.
Ilya A. Volynets-Evenbakh wrote:
>Eeee.. It makes no sense. Why have
>Common log interface if you still
>need to know which specific kind of
>Logger you are working with?
>
>Btw - all those things do make sense
>For all mentioned kinds of logs.
>
>Think about marking records accordingly and filtering them later on.
>
>-----Original Message-----
>From: Alexey Parshin <alexeyp@gmail.com>
>Date: Tue, 31 Jan 2006 13:07:40
>To:C++ Servlet Engine Discussion <cppserv@total-knowledge.com>
>Subject: Re: Log class problems
>
>I don't want single CLogStream! I want to have several classes that are
>really easy to customise.
>Some elements of CSysLog class, like facilities, have absolutely no use for
>CLogFile.. And the file name in CLogFile means nothing for CSysLog.. And
>both, facilities and filename, mean nothing for CMemoryLog.
>
>I want only one change for now. I want to rename CLogFile to CFileLog, and
>separate it from CBaseLog - to different file. File names should change
>accordingly.
>
>2006/1/31, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>
>
>>In my method, one would need to override single function just as well.
>>Most of your current overflow() code would stay the same - just the
>>virtual saveLog() function would need to be overwritten. This isn't
>>any more complex then what you propose.
>>
>>There are reasons, why C++ iostreams are designed the way they are.
>>In the design I'm proposing one wouldn't need to derive from CLogStream
>>_at all_. There would be singel CLogStream class, that provides intrfaces
>>for setting log priorities and stuff like that, that are common to all log
>>classes, and then it would be used with different buffers for different
>>destinations.
>>
>>(This is slight deviation from my original thinking, where I didn't
>>realize
>>there is no need to further derive CLogStream)
>>
>>
>>Alexey Parshin wrote:
>>
>>
>>
>>>2. I gave you my arguments. Writing a new log class is much simplier in
>>>
>>>
>>the
>>
>>
>>>current implementation. Considering that I'm not trading off anything -
>>>that's enough. To add even more - I don't want to explain in
>>>
>>>
>>documentation -
>>
>>
>>>"don't you dare to overwrite overflow(), or it would stop working!".
>>>
>>>
>>Current
>>
>>
>>>implementation requires to ovewrite a single method with a parameters
>>>providing full info about what should be done. That's an idiot-proof
>>>
>>>
>>method.
>>
>>
>>>
>>>
>>>
>>--
>>Ilya A. Volynets-Evenbakh
>>Total Knowledge. CTO
>>http://www.total-knowledge.com
>>
>>
>>
>>
>
>
>--
>Alexey Parshin,
>http://www.sptk.net
>
>
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com