Author Topic: LogManager support for multiple logger for same app type  (Read 2127 times)

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
LogManager support for multiple logger for same app type
« on: February 03, 2022, 08:02:43 am »
I may not be using the right names, but hopefully this post can be understood.

In logmanager.h the following app types are defined:
Code
enum {no_index = -1, invalid_log, stdout_log,  app_log,  debug_log};

In the app.cpp the following block if you do not look at the underlying code you would assume allows multiple loggers (TextCtrlLogger, FileLogger,  StdoutLogger, NullLogger) for the same  LogManager::app_log or LogManager::debug_log:
Code
if (parser.Found(_T("no-log")) == false)
    Manager::Get()->GetLogManager()->SetLog(new TextCtrlLogger, LogManager::app_log);
if (parser.Found(_T("log-to-file")))
    Manager::Get()->GetLogManager()->SetLog(new FileLogger(_T("codeblocks.log")), LogManager::app_log);
if (m_HasDebugLog)
    Manager::Get()->GetLogManager()->SetLog(new TextCtrlLogger, LogManager::debug_log);
if (parser.Found(_T("debug-log-to-file")))
    Manager::Get()->GetLogManager()->SetLog(new FileLogger(_T("codeblocks-debug.log")), LogManager::debug_log);
But the Manager::Get()->GetLogManager()->SetLog(....) code does not allow multiple loggers for the same app types (parameter i)

Code
size_t LogManager::SetLog(Logger* l, int i)
{
    unsigned int index = i;

    if (i <= no_index)
    {
        for (index = debug_log + 1; index < max_logs; ++index)
        {
            if (slot[index].GetLogger() == &g_null_log)
            {
                slot[index].SetLogger(l);
                return index;
            }
        }

        delete l;
        return invalid_log;
    }

    slot[index].SetLogger(l);
    return index;
}

I have been pulling my hair out as there is no error message if the app.cpp block tries to register multiple loggers.
Is there any reason that the code as to why the code could/should not be enhanced to support multiple loggers for the one app type so the logs can be shown on the console/gui and also logged to a file? Before I do anything I thought I should ask as I am puzzled as to why the someone has not updated the code to support multiple loggers.



Just for completeness the log level log function follows that calls the logger type to do the logging:

Code
void LogManager::LogInternal(const wxString& msg, int i, Logger::level lv)
{
    if (i >= 0 && i <= max_logs && slot[i].log != &g_null_log)
        slot[i].log->Append(msg, lv);
}

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3264
Re: LogManager support for multiple logger for same app type
« Reply #1 on: February 03, 2022, 10:48:14 pm »
The question is what comes after this....
What do you do when loggers support other  output paths?
Add UI for setting files?
What do you do with this? Can you not simply copy all and paste it?

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
Re: LogManager support for multiple logger for same app type
« Reply #2 on: February 03, 2022, 10:56:58 pm »
You are right. I did not think that far into the future.

Offline AndrewCot

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 678
Re: LogManager support for multiple logger for same app type
« Reply #3 on: February 04, 2022, 11:32:36 am »
Is there any docs or wiki pages on the logger/logging in C::B?
The logging seems a bit old and not fully finished. It does not use what I would call the new logging level type standards used by Log4xxx/Winston etc as the logging levels are defined, but I cannot see any code that uses it (look in loggers.cpp for the "::Append" functions). There are gaps in my understanding of the logging sub system that I only spotted after starting to re-work the code to support multiple types of loggers and as such the code I ended up with is a real frankenstein hacked POC that runs, but is going no where and an confident that there is a 75% chance it will go into the bit bucket and I will have to start again in a few days.
Saying the above has anyone looked at the loggers and thought about how it could be refactored/rewritten/changed for the better (no mater how small the better is). If you have can you PM info or let me know where I can look to see if I can reuse/borrow and of the proposed or actual code changes as this may save me time and effort.
So much for my original thinking that the logger changes taking a say 4 to 6 hours of work. Now I think it will take as long as it takes, which is going to be a while as it probably needs a proper design doc.