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 <apa...@bago.org>: > 2011/12/31 Eric Charles <e...@apache.org>: >> 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 interface and then >>> use an adapter to slf4j). >>> >> >> Hi Stefano, >> I am more in favor of #2 to keep things simple. >> For which reason do you prefer #1? > > Because as a user or a library I prefer to write an adapter (5 > minutes) instead of being forced to use a given logging toolkit. > > History clearly shown us that choosing a logging framework is never a > good idea: just count how many products moved from one logger to > another in the last 10 years. I bet 90% had to do that! So if a couple > of interfaces allow us to encapsulate logging I think it is much > better. > > Also, encapsulating it for a library gives one more opportunity as it > allows the library user to intercept/monitor/alter the log calls. > The best thing would be to name the specific logger interface > something like "Monitor" (and not Logger) and use domain specific > calls that will be converted to log calls only by the wrapper. > > We did this in mime4j and it worked fine (it even allowed us to > introduce new features using the "monitor" in a special way to deal > with strict/lenient parsing)! > > So, IMO, the "best practice" is that libraries should not provide > logging at all. Logging is needed by applications (and not libraries) > because the application user is an human and can't interface > differently, instead library users are applications (or other > libraries) so they can communicate much better than using a log file. > >>> I also think that an slf4j adapter could be provided direclty in the >>> protocols project and used as an optional dependency (so you don't >>> have to write the adapter in every project). >>> The "right" approach would be to have a protocols module with the >>> slf4j adapter, but IMO a module for a single class is too much, so >>> maybe we can simply put the adapter in the netty module or in the api >>> module and then declare the slf4j dependency as optional, so that >>> users of the library will decide if they want to use the slf4j logger >>> or instead provide their own implementation. >>> >> >> Yes, it would be crazy to ask to all our library users to reimplement that >> adapter. >> >> To open the discussion more, I already saw (don't remember which ones) needs >> for a "james-common" that could be useful to all our projects. Some logging, >> streaming,... classes could perfectly fit there. > > 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. > All of this PITA could have been skipped if only java.util.Logging > provided an interface or commons-logging provided also an interface > for the logger factory, but this never happened and I guess it won't > happen anymore, so we are forced to do that. > >>> I'm not sure if this plays well with OSGi. >>> >> >> No idea... but I don't see why it couldn't > > I have limited experience with OSGi but I remember optional > dependencies created me some issue, but maybe this is because I was > not skilled enough to deal with that... so I hope someone else > (Norman) will answer this doubt. > > Stefano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
