Re: Log class problems

[Alexey Parshin <alexeyp@gmail.com>]

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.

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.

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