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 integrati
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
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.apa
> 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
+1
On Sat, Dec 31, 2011 at 1:11 PM, Young Gu wrote:
> > 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 .
> -
2011/12/31 Eric Charles :
> 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 adapte
On 31/12/11 15:03, Stefano Bagnara wrote:
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?
IMO we should go with #1 (using a private Logger inte
Hi Stefano,
I would even put the slf4j adapter into the api package. Then make it optional
as you said. This will also work with osgi.
Bye,
Norman
--
Norman Maurer
Am Samstag, 31. Dezember 2011 um 15:03 schrieb Stefano Bagnara:
> 2011/12/31 Eric Charles mailto:e...@apache.org)>:
> > Hello
Hi,
As said, I am more in favor of uniformisation across projects, but I'm
also fine with an adapter.
I'm seeing the current 'server' projects more like components/librairies
like the other libraries, thus tend to apply the same rules to them.
Thx,
Eric
On 31/12/11 15:23, Norman Maurer w
2011/12/31 Eric Charles :
> On 31/12/11 15:03, Stefano Bagnara wrote:
>>>
>>> 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?
>>
>>
>> IMO
Hi Stefano, Comments inline.
Eric
On 31/12/11 15:52, Stefano Bagnara wrote:
2011/12/31 Eric Charles:
On 31/12/11 15:03, Stefano Bagnara wrote:
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 lo
Like I said, optional dependency works quite well with osgi. We did the same in
netty.
Bye
Norman
Sent from my iPhone. Excuse any typos
Am 31.12.2011 um 15:52 schrieb Stefano Bagnara :
> 2011/12/31 Eric Charles :
>> On 31/12/11 15:03, Stefano Bagnara wrote:
but didn't know where
2011/12/31 Eric Charles :
> Hi,
>
> As said, I am more in favor of uniformisation across projects, but I'm also
> fine with an adapter.
(I'm not trying to push my idea, but instead trying to explain you my
thinking, as we talked about this a bunch of times in the past years)
Logging is a very pec
2011/12/31 Eric Charles :
> A Logger is a logger.
I agree, but then I would say that most times we abuse "loggers" :-)
> For monitoring purposes, I would not generalize the Logger to be a Monitor.
> But this is way beyond our discussion on the logging libraries :)
Apple vs Oranges or better Aspe
Hi Stefano,
to be honest I like the "monitor" idea but its a bit hard to implement in a
useful way in the ProtocolSession. This is because users will write their own
ProtocolHandler implementation and want to log different things there. How
would you fulfill the need of that with a "monitor" ?
2011/12/31 Norman Maurer :
> Hi Stefano,
>
> to be honest I like the "monitor" idea but its a bit hard to implement in a
> useful way in the ProtocolSession. This is because users will write their own
> ProtocolHandler implementation and want to log different things there. How
> would you fulfil
Hi there,
I will review the Monitor usage in mime4j and then come back to you..
Have fun,
Norman
Von meinem iPad gesendet
Am 31.12.2011 um 18:10 schrieb Stefano Bagnara :
> 2011/12/31 Norman Maurer :
>> Hi Stefano,
>>
>> to be honest I like the "monitor" idea but its a bit hard to implement i
On 31/12/11 17:47, Stefano Bagnara wrote:
2011/12/31 Eric Charles:
A Logger is a logger.
I agree, but then I would say that most times we abuse "loggers" :-)
sometimes we abuse, and often we are quite happy to have them.
How many times don't we ask our users to raise the debug level from i
Hi Stefano,
I agree with your arguments as with mine :)
I think there is not only one valid answer to this. If there was one,
everybody would do that way.
Eric
On 31/12/11 16:32, Stefano Bagnara wrote:
2011/12/31 Eric Charles:
Hi,
As said, I am more in favor of uniformisation across projec
2012/1/1 Eric Charles :
> "Better Java Development with AspectJ" (I think the ppt is no more online)
> from PARC clearly points the logging as a perfect candidate to aspect
> programming.
I saw logging always as a case in AOP books, but I never really saw a
real project using AOP for logging, so I
2012/1/1 Eric Charles :
> Hi Stefano,
>
> I agree with your arguments as with mine :)
> I think there is not only one valid answer to this.
So True!
> If there was one, everybody would do that way.
Not so sure about this ;-)
Stefano
-
Thx for the discussion Stefano.
(see my comments in line).
As Norman, I will look to the Monitor usage in mime4j and we could try
to go that way with a Slf4jLoggerAdapter provided in protocols-api (btw,
this will have as consequence to re-add the dependency to slf4j in
protocols-api's pom).
On 02/01/12 08:56, Eric Charles wrote:
As Norman, I will look to the Monitor usage in mime4j and we could try
to go that way with a Slf4jLoggerAdapter provided in protocols-api (btw,
this will have as consequence to re-add the dependency to slf4j in
protocols-api's pom).
btw, already done by N
Hi,
I started the integration of protocols trunk in server (still 55 errors
and downcounting).
This gives funny adaptation like this (in ImapChannelUpstreamHandler)
private Logger getLogger(Channel channel) {
return new Slf4jLoggerAdapter(new ProtocolSessionLogger("" +
channel.getId(), new
24 matches
Mail list logo
