On Jul 14, 2008, at 10:13 AM, Craig L Russell wrote:
On Jul 11, 2008, at 10:31 AM, Alan D. Cabrera wrote:
On Jul 11, 2008, at 10:11 AM, Les Hazlewood wrote:
So, does that mean everyone is ok with our preferred logging
_implementation_ being SLF4J and that I can remove Commons Logging?
Putting a finer point on it, I am ok with the preferred logging API
being SLF4J. Removing commons logging would be great.
I would still prefer to see a wrapper api like I suggest, but that
doesn't mean I can't incorporate SLF4J now as long as everyone is ok
with that. The wrapper API is not dependent on our preferred
logging
implementation.
As I've mentioned before, if the wrapping API provides the same
functionality as SLF4J then you may as well use the SLF4J API.
It sounds like this is the crux of this issue. Do you want to import
an external logging framework (e.g. org.slf4j.Logger) into every
class in the project or import a project-specific interface (e.g.
org.apache.jsecurity.Logger) into every class?
When I've done this kind of thing in other projects, I started with
the requirements of the project for logging and defined the
bootstrap and interface local to the project. That meant defining a
LoggerFactory and Logger using the package names of the project.
The advantage of defining logging solely within the project is that
you don't tightly bind an external package to each class in the
project. I'd consider this to be best practice.
For the implementation of the logger interfaces, you can choose
whatever framework is suitable. And if a user wants to employ a
different logging framework, only a bootstrap class is needed in
order to change the implementation.
From the code I looked at in sourceforge, it's not quite there yet.
There seem to be hard-coded dependencies on the logger framework not
on a local interface.
I think that there are times when these kind of draconian measures are
needed. You mention that your project started out with those
requirements. I and the rest don't see that need in this case.
Regards,
Alan
