[slf4j-dev] [Bug 163] Copy & paste of LoggerFactory.getLogger

[bugzilla-daemon at pixie.qos.ch]

http://bugzilla.slf4j.org/show_bug.cgi?id=163

--- Comment #38 from Thorbjørn Ravn Andersen <thorbjoern at gmail.com> 2011-03-20 19:53:24 CET ---
(In reply to comment #35)
> Michael Glauche has come up with a solution using Guice[1]. Given that Guice
> has or will have support for JSR 330, we could perhaps propose a "standardized"
> solution based on JSR 330. 

I have now spent quite some time making JSR-330 work as we want it to with the
current main implementations Spring, Guice and Weld as possible backends.  An
interesting exercise.

The conclusion was that a standard way for the user to use a SLF4J Logger with
JSR-330 _is_ possible, but it must contain JSR-330 implementation specific
code.

The reason for this is that JSR-330 specifies a well-supported "Provider" 
(think Factory) concept but the API is very limited and does e.g. not provide
any information about _where_ the provided object is to be used which is needed
here.  In order to get that information the actual backend needs to be asked,
and this is not standardized. 

Also _configuration_ is outside the JSR-330 scope, so it is also backend
specific, but not that difficult.

Basically there are two approaches as I see it now, one for using @Inject, and
the other for a custom @SLF4JLogger annotation without @Inject.  The
implementations are vastly different but the syntax is quite close:

1)  @Inject Logger log;

2) @SLF4JLogger Logger log;

so this is a matter of taste.  Personally I think the @SLF4JLogger will be the
most robust as it is separate from other @Injects.

The Guice folks made a very important recommendation, namely that they
recommend a public setter method for all injectable fields so that the _setter_
is invoked setting the field, instead of just putting the value in the field. 
The reason for this is that it allows you to unit test your code as plain
classes without a JSR-330 environment active - remember it is just meta-data. 
I think this is both true and so important that this might be a good reason to
reconsider the age old "private static Logger log =
LoggerFactory.getLogger(....)" paradigm.   

If so, the new paradigm will be


Logger log;

@Inject
public void setLogger(@SLF4JLogger Logger log) {
  this.log = log;
}


This might be a very good idea for a "SLF4JLogging" (SLF4JLoggable?) interface.

-- 
Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.