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.
Regards, Craig
Regards, Alan
Craig L Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
