Opened 6 years ago
Closed 6 years ago
#12402 closed Feature Requests (fixed)
knowing the current filename used by a boost.log text_file_backend
Reported by: | Owned by: | Andrey Semashev | |
---|---|---|---|
Milestone: | To Be Determined | Component: | log |
Version: | Boost 1.60.0 | Severity: | Problem |
Keywords: | text_file_backend | Cc: |
Description
I am trying to use the Boost.Log library and am quite pleased with it so far. (I am transitioning from log4cxx.) Before getting into the details, let me say why I am asking this question.
- I need to populate a status line to tell an administrator the path to the current output log file.
- On shutdown (and at any point really), I need to provide a summary that points a user to the path of the last output log file.
As far as I can tell I am unable to meet either of these requirements with the 1.60 implementation of the Boost.Log text_file_backend
. Regarding the first requirement the
text_file_backend
provides open and close handler methods, but those use a stream argument and they are intended to be used to write header and footer text to the output stream when a file is opened or closed. But I need to know the *filename* of the stream that is opened.
Regarding 2, the file_collector store_file
method takes a source path. But I need to know the destination path not the source path. I do not see anything that exposes the final destination where the collector has stored my files.
As a user of Boost.Log 1.60 is there a way to meet either of these requirements through the current API? If not, any suggestions on the best way to proceed?
Change History (3)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
I have modified text_file_backend so that it meets my requirements. I did this by:
- adding to the open and close handler a string argument for the filename of the stream; the stream filename is readily available from m_pImpl->m_FileName where the open and close handlers are called by text_file_backend::consume and text_file_backend::close_file.
- adding to the collector interface a set_store_handler callback method that the file_collector implements so it may use the callback in its implementation of the store_file method.
Right now I have put these changes in a copy of text_file_backend that I have incorporated into the source code of my local project. If you are interested, I can put these changes into a pull request for Boost.Log. As far as I can see, the changes are quite small and seem to fit in well with your text_file_backend implementation. Unfortunately, change (1), modifies the current text_file_backend open and close _handler_type types, so it will affect compatibility. I am not sure how, if at all, you want to deal with API changes.
I do, however, think the improved functionality my changes provide are important. Without these changes, I cannot meet either of my requirements. I would like to get this functionality into a future Boost.Log release as I do not like either choice of maintaining my own hacked copy of text_file_backend, or my own distribution of boost.
Thanks for all of your effort on Boost.Log!
comment:3 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Added a method to obtain the current log file name from the text file sink backend in https://github.com/boostorg/log/commit/a74e9d4a74dabe912f5eeeac3b7a987ad1c5b2e1.
There is no API to obtain the current file name. You could try implementing your own log file collector. Basically, the collector implemented in Boost.Log does not rename the file, it only moves it to the target directory, which you specify when you create the collector. So by implementing
collector::store_file
you should be able to know the full path to the last rotated log file. The currently written file name is inaccessible, you'll have to patch the library to change that.