CPPSERV


Home Projects Jobs Clientele Contact

cppserv


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Log class problems



Alexey Parshin wrote:

>Priority does make sense for all of them. It's already implemented.
>Facility - doesn't.
>
>The code:
>
>getContext().getLogger()<<warning<<"Moo"<<std::endl;
>
>works just fine in the current implementation, except it's not 'warning' -
>it's CLP_WARNING.
>  
>
If you look at it this way, setting up facility shouldn't be part
of Stream interface, but rather should be init parameter of
relevant StreamBuf - after all different facilities are usually
different streams anyways. Even in syslog API you'd have
to reopen log in order to change it.

>I'm now implementing everything the compatible way - to make sure it works
>the same way under any environment. Of course, syslog api doesn't work under
>Winblows.
>  
>
You have EventLog there, which is a similar thing.

>2006/1/31, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:
>  
>
>>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
>>
>>
>>    
>>
>
>
>--
>Alexey Parshin,
>http://www.sptk.net
>
>  
>

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com


Authoright © Total Knowledge: 2001-2008