> 2.- the uniformisation between all projects.
+1
slf4j is a good candidate, no the dependency nightmare.
Please be free to contact with me for any question or suggestion.
Thanks & Best Regards .
----------------------------------------------------------------------------
Young Gu | Software Engineer | http://www.infor.com
On 12/31/2011 03:35 PM, Eric Charles wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
