Re: Log class problems

[Alexey Parshin <alexeyp@gmail.com>]

Setting the facility currently is implemented in constructor (it isn't
in CVS yet). I don't really see the need to change it on the fly.

As for EventLog - it may be an idea. At least, it's something like
syslog api. But I need to read that API first before stating
anything..

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


--
Alexey Parshin,
http://www.sptk.net