Re: Logging library in our projects

[Eric Charles <er...@apache.org>]

On 31/12/11 17:47, Stefano Bagnara wrote:
> 2011/12/31 Eric Charles<er...@apache.org>:
>> 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 info 
to debug :)

>> 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 Aspects vs Pattern. Why can't you implement
> the Logging aspect of a given actor using a Monitor pattern?
> I find that if you use a monitor instead of plain "local logging" you
> also think better to the meaning of what you want to log and to the
> target of the log (user? developer? bug hunter?).
> Also a monitor can help during unit tests, instead "standard logging"
> doesn't help at all.
>

We can indeed extend the discussion and see how we could better 
architecture/design our logging functions.

"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 didn't remind the Monitor pattern, so I took back my books and found 
in the "Pattern oriented software architecture" a Monitor Object pattern 
to "synchronize method execution".

So to design such an architecture we could also take into consideration 
aspect programing, and be sure that a Monitor will not be confusing with 
the 'object monitor' responsible to manage the locks. btw Monitor is 
also used in JMX world, and in that way it could have more sense.

>> mmh, for me everything is a library and a library needs logging.
>
> I don't agree.
> A book is a sorted collection of pages but if you take a bunch of
> random pages and add a number to it you can do something that looks
> like a book but I wouldn't call "a book".
>
> So a library is a very specific subset of a "bunch of classes".
> We could also create 2 distinct worlds of libraries: libraries using
> IO and libraries not using IO.
>

A bunch of classes that can be reused in one than one use case.
Why distinguish IO vs non-IO ?

>> An application is just a composition of libraries.
>
> An application is another subset of a "bunch of classes", using IO,
> and providing a "main" function. You don't need composition to create
> an application, instead you need a "main" to do that!
> I can't really call every application "a library".
> Every subset needs special consideration, so I'm not ready to find a
> "one fit them all" solution.
>
> (I'm not saying that mine explanation of words is better than your,
> just explaining how I used words, when I used them)
>

So an application is a library with a class with a main :) (just kidding)

>> If I follow your reasoning, nor protocols nor server would need logging?
>
> In my language, server is an application and needs logging. protocols
> is a library and should better use monitoring instead of logging. If
> server wants to log something happening in protocols then can simply
> monitor the procotols and log monitored things.
>
>> Also, logging can be configured with appenders to log in database, jms
>> queues... and even in mails (for error level for example) :)
>
> Sure, but it is not really easy to add "monitorability" ta library
> that makes use of logging.
> Instead is easy to add "logging" to a library that use a monitor pattern.
>
> So if we use a monitor like pattern (a dependency inject Logger
> interface , despite the name, is an implementation of a monitor) we
> allow users to define what to do.
>
> I love the approach of pico-container loggin (unfortunately I guess it
> is a dead project). I find this page really influenced my thought:
> http://svn.codehaus.org/picocontainer/java/2.x/trunk/logging/src/site/content/monitor-pattern.html
>

Seems like pico container has/had much to give.

>>> I don't like the james-common solution as it would be one more
>>> dependency anyway and it doesn't make sense if it can be reduced by
>>> just adding 2 classes in each library.
>>
>> 2 classes for logging, 3 more classes for something else, that could save us
>> some code and maintenance, but yes, it also needs a release, that's not
>> piece-of-cake...
>
> You would end up with a "catch-all" module where you put everything
> that is used by at least 2 modules.
> After few years using this approach you will have a 2MB catch-all
> library and your protocol library will depend on "james-catchall", a
> 2MB jar from which we only use 2 logging classes.
>

I don't push for james-common atm, but what could be there is just what 
developers decide to put. Good or bad design/content is applicable for 
any library, not only a potential james-common.

> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

-- 
eric | http://about.echarles.net | @echarles

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Logging library in our projects

[Eric Charles <er...@apache.org>]

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 ProtocolLoggerAdapter(logger)));
}

fyi,
Eric


On 02/01/12 09:09, Eric Charles wrote:
> 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 Norman with optional slf4j dependency.

-- 
eric | http://about.echarles.net | @echarles

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Logging library in our projects

[Eric Charles <er...@apache.org>]

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 Norman with optional slf4j dependency.
-- 
eric | http://about.echarles.net | @echarles

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Logging library in our projects

[Eric Charles <er...@apache.org>]

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).

Eric

On 02/01/12 01:10, Stefano Bagnara wrote:
> 2012/1/1 Eric Charles<er...@apache.org>:
>> "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 can't tell if it works fine
> or not. IMO most logging happens inside methods and not
> before/after/around so I don't expect AOP to solve the logging
> problem, but I'd be happy to learn I'm wrong here.
>

Same here.

>> A bunch of classes that can be reused in one than one use case.
>> Why distinguish IO vs non-IO ?
>
> I'm used to do this. IO is a "dependency", and an "hard" one for a library.
> Maybe this has something to do with my studies in functional programming.
>

So true.

>> So an application is a library with a class with a main :) (just kidding)
>
> An apple is a fruit.
> A banana is a yellow fruit.
> A yellow apple is a yellow fruit.
> So a yellow apple is a banana.... not sure ;-)
>

I don't know, but I like to eat apple, banana and oranges, although 
oranges are not yellow :)

> Happy new year!

All the best!

> Stefano
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>

-- 
eric | http://about.echarles.net | @echarles

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

Re: Logging library in our projects

[Stefano Bagnara <ap...@bago.org>]

2012/1/1 Eric Charles <er...@apache.org>:
> "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 can't tell if it works fine
or not. IMO most logging happens inside methods and not
before/after/around so I don't expect AOP to solve the logging
problem, but I'd be happy to learn I'm wrong here.

> A bunch of classes that can be reused in one than one use case.
> Why distinguish IO vs non-IO ?

I'm used to do this. IO is a "dependency", and an "hard" one for a library.
Maybe this has something to do with my studies in functional programming.

> So an application is a library with a class with a main :) (just kidding)

An apple is a fruit.
A banana is a yellow fruit.
A yellow apple is a yellow fruit.
So a yellow apple is a banana.... not sure ;-)

Happy new year!
Stefano

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org