mixing up log4cplus through direct usage and dcmtk usage

[Markus Sabin]

Dear OFFIS team,

I am using dcmtk in a project wich already uses log4cplus. I have not completely boiled it down yet, but apparently this causes a clash in thread synchronization (something like trying to lock a mutex with the same name twice). My preferred way of solving the issue would be to use the (more recent) log4cplus that is already included in my project. If this is not possible I'll probably have to redirect the current calls to the logging framework to the oflog logger.

My questions are:
- is there some pattern for a solution that you had in mind for this situation when wrapping the log4cplus namespace in the oflog namespace?
- can I expect to have the full functionality available in the log4cplus library on oflog::log4cplus as well or did you apply additional modifications to log4cplus beyond wrapping it to the namespace.

I do not expect an elaborate answer, but a little pointer in the right direction might save me days...

Thanks

Markus

[J. Riesmeier]

Hi Markus,

we know that it would be useful to (optionally) replace the builtin log4cplus version by an external (more recent) one. See this feature request (unfortunately, it's still in German but I know that this is not an issue for you ).

The reason why we have this builtin log4cplus code in the DCMTK is:

• This package is required in order to compile the DCMTK (in contrast to the other external libraries).
• We did some modifications to the log4cplus source code, e.g. in order to compile with OFString (instead of std::string), in order to adapt the output to our needs, in order to make use of the system configuration settings determined by DCMTK's "configure" or "cmake" process, in order to compile on the platforms supported by the DCMTK...

But now to your two questions:

- is there some pattern for a solution that you had in mind for this situation when wrapping the log4cplus namespace in the oflog namespace?

The "dcmtk::log4cplus" namespace has been introduced with this commit. As far as I remember, this has been done in order to avoid name conflicts with multiple log4cplus packages being used in a single application (like in your case). So, the trigger for doing this came from some DCMTK user.

- can I expect to have the full functionality available in the log4cplus library on oflog::log4cplus as well or did you apply additional modifications to log4cplus beyond wrapping it to the namespace.

As I said, we did some minor modifications (see above). Without looking into the code, one additional difference (I can remember) was/is that we introduced a new output pattern "%P" in order to use only the first character of the log level (T, D, I, W, E, F). This was not possible with log4cplus years ago, but should be possible (by some other means) with the current version (as far as I know). Also, we have a patch to log4cplus that treats each line of a log message separately (see above referenced feature request).

Bottom line: If you are willing to contribute a patch that updates DCMTK's log4cplus version to a more recent one [*], this would be warmly welcome. I could also send the short instructions to you that the person who did this integration work in the past left to us (again in German language).

[*] Also see this feature request: http://support.dcmtk.org/redmine/issues/404

[Markus Sabin]

Hi Jörg,

thank you for your quick and helpful reply. I would definitely like to contribute to your great toolkit, so I will take your proposal into serious consideration. However, I am not looking for sophisticated logging features, I rather want to be able to apply important patches to log4cplus in case critical bugs are found and fixed as I would like to use it in the field of medical applications like many of its users do (I suppose so) and avoid linking to 2 "different" third party libaries which basically do the same thing.

So my approach would be to seek for a way to redirect the dcmtk output to a log4cplus::Logger already present in the application. If I find a solution for this I will provide it to you for sure, however I would not be able to care about compatibility with the variety of platforms that dcmtk supports. I am not an expert in this.

For the project I am currently working I will probably try the opposite thing: introduce a "WITH_DCMTK_LOGGER" option which redirects our calls to log4cplus to the oflog::log4cplus implementation.

BTW: Meanwhile it has turned out that a "thread synchronization clash" is not the cause for my issues. It is related to log4cplus but not to dcmtk and its use of it.

Thanks again and have a great weekend

Markus