Hello Norman,
Yes, I can understand this.
So, how are we gonna create a POP3Protocol(ProtocolHandlerChain,
ProtocolConfiguration, Logger) from server which uses slf4j?
We need to give as third parameter a org.apache.james.protocols.api.Logger.
An adapter between org.slf4j.Logger and
org.apache.james.protocols.api.Logger could do the job, even if find
this a bit overhead.
When integrating server and protocols trunk a few days before, I thus
though to these 2 options:
1.- the adapter.
2.- the uniformisation between all projects.
but didn't know where to go..., this is the reason for this thread :)
Maybe you have a third option in mind such as having two completely
separated logging mechanism when running protocols in server?
Thx,
Eric
On 30/12/11 21:25, Norman Maurer wrote:
Hi Eric,
I pulled out the slf4j dependency in protocols as its really sexy to have zero
dependencies in the API. We even only used the Logger interface which made it
even more clear to me that we should use our own logger interface.
Our implementations and so consumer of the API will still use slf4j.
We did the same in jSPF.
Hope it helps,
Norman
Von meinem iPhone gesendet
Am 30.12.2011 um 20:48 schrieb Eric Charles<[email protected]>:
Hi,
I noticed:
- https://issues.apache.org/jira/browse/JAMES-1149 (Replace commons-logging
with jcl-over-slf4j)
- and recent https://issues.apache.org/jira/browse/PROTOCOLS-76 (Remove
dependency on slf4j)
I commented on the PROTOCOLS-76 about the incompatible types which makes the
integration of our different project more complicated (incompatible logger
types in constructor,...).
One option is to standardize for all project to one of the following:
1.- slf4j
2.- java.util.Logger
3.- commons-logging
4.- Our own implementation
5.- ...
I don't have any strong preference for any, but the trend I see in some (not
all) other projects is slf4j.
If we go this way, this will give us probably less work to integrate
server-trunk with protocols-trunk.
...or let each project decide, which will be hell.
WDYT?
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
eric | http://about.echarles.net | @echarles
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
