Logging conditionally repetitively in code
There are a few remarks that come to my mind.
Simplifying the logic
In your sample code, the two different log strings for success and failure don't differ too much. So I guess the following strings might be acceptable to you as well:
&quot;Setting read callback hook: successful&quot;
&quot;Setting read callback hook: FAILED with status nnn&quot;

Then you can create a static method statusText(int status) e.g. in a Utils class that returns &quot;successful&quot; for status==0 and &quot;FAILED with status nnn&quot; in all other cases. If I understood correctly, such a statusText() method should be re-usable all over your application, assuming that 0 always means success.
And then you can do the logging like:
LOGGER.info(&quot;Setting read callback hook: &quot; + Utils.statusText(status));

But there are a few other issues:
Log Levels
Log4J has different log levels, and you shouldn't ignore that aspect. Depending on the consequences, a failure should typically get the ERROR level, at least the WARN level. So, in case of a non-zero status, LOGGER.error() seems to be a better choice.
INFO is meant for messages useful to the system administrator running the site. Messages targetting the developer should get a lower level, typically DEBUG or TRACE. I guess, the success of setting some callback isn't important to the system admin. The admin typically only wants to see things needing his/her special attention. So, I'd change the success case to LOGGER.debug().
Of course, then my statusText() solution no longer fits, as that doesn't support different log levels.
Why not Exceptions?
Your code sticks to the 1970s status code pattern to communicate failure (return an integer where some values mean success and others mean failure). By the 1990s, the software industry had learned that error handling can be done in a better way using exceptions.
So, instead of returning int values and forcing each and every layer of your software to check for the success results, throw an exception if something like setting a callback failed. By embracing exceptions as the signal of failure, your code typically becomes

cleaner,
more readable,
more compact,
more focussed on the main task instead of the failures
and more robust.

The simple guidelines for exceptions are:

If a method can't fulfill its job (whatever you defined that job to be), it throws an exception.
If a method returns normally, the caller can rely on the fact it has successfully done its job.
You catch an exception only if you know a way how to continue successfully even after an internal failure, e.g. by retrying.