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" ?
Thanks, Norman -- Norman Maurer Am Samstag, 31. Dezember 2011 um 17:47 schrieb Stefano Bagnara: > 2011/12/31 Eric Charles <e...@apache.org (mailto:e...@apache.org)>: > > 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 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. > > > 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. > > > 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) > > > 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 > > > > 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. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > (mailto:server-dev-unsubscr...@james.apache.org) > For additional commands, e-mail: server-dev-h...@james.apache.org > (mailto:server-dev-h...@james.apache.org) > >
