This is exactly my desired effect Craig. Thanks for chiming in. Please do an SVN update - I checked in my last code edits maybe 20 minutes ago. The total result is 2 interfaces and 7 implementation classes, all one line method implementations. That's it and I've tested it and consider it code complete. If used, none of our classes are forced to import the 3rd party APIs.
The most important implementation is JSecurityLogFactory - please look at the source code and you'll see how I do my graceful degredation check. That is really all there is to it, plus the one-liner methods of the respective Log implementations. I also consider this a best practice and worth the (trivial) effort it took me. On Mon, Jul 14, 2008 at 1:13 PM, Craig L Russell <[EMAIL PROTECTED]> 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. > > 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! > >
