5

I am having a problem with using Boost Logging library, that if I add a formatter or a destination to a logger, using my own Log class, I cannot change that destination or formatter.

Does anybody know how to change the destination or formatter on a boost log object?

The scenario I have is that I want a different destination (file name) for each request my server component handles, so I need to have flexible way to change them. Also the fact that I will be logging from different thread simultanuously, and each Log should really have it's own destination's, easily added - removed.

The fact that with the macro's the logging objects are really app global, does not really aid this.

Can anybody give me some guidance on how I can create a flexible way to add/remove destinations to a Logger from boost::logging?

Tony The Lion
  • 61,704
  • 67
  • 242
  • 415
  • 1
    It would be nice if your question had some key words hyperlinked, so I didn't have to use google to find the documentation. – Daniel Lidström Dec 17 '10 at 09:18
  • The example: `g_l()->writer().add_destination( destination::file("out.txt") );` does not work for you? – Daniel Lidström Dec 17 '10 at 09:27
  • yes add works, however it adds it to a global g_l object and so when you add a new destination to the same g_l, it now writes to 2 destinations, instead of just the last one, which is what I want. – Tony The Lion Dec 17 '10 at 09:35
  • Can you clarify a bit? Are the logs per component, or per thread, or, per component and thread. I guessing you have fixed number of components (where each component could be running under multiple threads), and you want each component to log in its own file ? – jyoung Dec 26 '10 at 15:25

1 Answers1

2

Ok, here's what I would try. It might work for you. It looks as if the logging library is tailored for global loggers, while you are wanting to use thread-local loggers. I'd look up how to create a logger on demand (i.e. directly), for example by analysing BOOST_DECLARE_LOG. Then you can declare a std::map<int, Logger> that you use to map thread-id to specific logger. Probably you can create your own wrapper class that handles this transparently for client code. Then you just log using your own logging layer and create thread-specific loggers when needed. If you need to remove them after your request is finished you can add a method to do this.

Hope this helps!

Daniel Lidström
  • 9,930
  • 1
  • 27
  • 35
  • it sounds good, but looking at the BOOST_LOG_USE_LOG_IF_LEVEL macro implementation, I don't think I know how to use that without that macro... – Tony The Lion Dec 17 '10 at 10:38
  • Great, thanks. I actually did try to help you, but now you're on your own. Good luck. – Daniel Lidström Dec 17 '10 at 11:02
  • that wasn't meant as something to make less of your help, I appreciate your time and effort, I was just saying that I don't think I can manage with that complex macro implementation above. – Tony The Lion Dec 17 '10 at 11:06
  • Neither did I downvote your answer, I'll do an upvote, because at least you tried to help. – Tony The Lion Dec 17 '10 at 11:07
  • 2
    Alright, thanks for clarifying. Sorry for jumping back at you. Anyway, it seems as if the chosen logging library has conflicting requirements. You need to create loggers dynamically, while this one wants to declare them statically. Sometimes the best thing is to write your own library, one that fulfils the requirements. You can always reuse the ideas from Boost.Logging that you liked. Good luck! – Daniel Lidström Dec 17 '10 at 11:58