qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Harvey <p...@philharveyonline.com>
Subject Qpid-specific logging facade(s) for Proton etc
Date Wed, 05 Jun 2013 14:27:32 GMT
An interesting discussion about logging has emerged from the mailing thread
"AMQP 1.0 JMS client - supplementary coding standards".  I'm starting a new
thread for this specific topic and am including the proton list.

To recap, Rob, Rajith, Rafi and Gordon have expressed a desire for Proton
and the new JMS client to use a custom logging facade, rather than directly
calling log4j, slf4j etc.  The Proton logging facade would work
consistently across proton-c and proton-j.

I think the case for adopting this approach is overwhelming, but am
interested in views on the best implementation.


*=== Proton ===*
*
*
I added a diagram to the wiki illustrating how this might work for
proton-j.  It's not finished, but I thought it useful to share it early to
stimulate discussion.  Hopefully the implied proton-c equivalent is fairly
obvious.

https://cwiki.apache.org/confluence/display/qpid/Proton+Logging

I'm not sure what would go into ProtonOperationalLogger at the moment
(Rob/Rafi may know), but want to leave the door open to separating
Proton-specific methods from general purpose log(Level, String) kind of
stuff.  It does at least give us a place to define the behaviour of the
"public logging API" that Rob referred to, and which would behave the same
as its proton-c counterpart.

To me, the Logger interface in the diagram looks very similar to the Qpid
Java Broker's RootMessageLogger.  Proton *may* use it directly for debug
logging.


*=== JMS Client ===*
*
*
Turning to the JMS client, my initial preference would be to create
interfaces JmsOperationalLogger and JmsLogger corresponding to the Proton
ones.  The JMS Client would pass to Proton a ProtonLogger implementation
that simply wraps its JmsLogger.

Alternatively we could create a Logger interface in a central sub-project
and use it in both Proton and the JMS Client, but I suspect that will
involve more re-jigging of our project structure than we currently have
appetite for.

Comments/criticisms etc welcomed.  I'm especially interested in whether
there are proton-c-specific factors that would significantly affect our
implementation.


Phil

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message