Suggestion: use SLF4J API

[ceefour]

When I see this: http://docs.jboss.org/modeshape/2.5.0.Beta1/api/org/modeshape/common/util/Logger.html

what I immediately had in mind is simply to replace that interface with org.slf4j.Logger

The relevant methods in ExecutionContext:

public Logger getLogger( Class<?> clazz ) {...}

public Logger getLogger( String name ) {...}

can then simply delegate to SLF4J's LoggerFactory.getLogger(....);

Then, ModeShape can simply depend on slf4j-api, requiring and freeing the application developer to choose whatever backend he wants.

Less cruft and code to maintain in ModeShape.

slf4j-api is also very efficient and fast.

Hopefully this idea is accepted. I'd be happy to contribute.

[rhauch]

Thanks for the suggestion, Hendy.

We already use the SLF4J API within ModeShape, as it allows applications that use or embed ModeShape to have ModeShape log messages sent to the application's logging system.

However, we chose quite some time ago to put our own lightweight layer on top of SLF4J, and there are two reasons why. The first is that our Logger class is a simple interface, and so having our own layer insulated us from SLF4J and allows us to actually switch to a different mechanism in the future, if we want to do that. But the most important reason is that our Logger class enforces internationalized messages for INFO, WARN, and ERROR messages. That's not something that can be enforced with SLF4J. Note that our Logger class does not actually localize the I18n instances unless the log message will actually be written per the logger's configuration.

So I would not be in favor of deprecating our Logger and replacing it with direct calls to SLF4J. IMO, this would be a lot of unnecessary work, and we'd lose the enforcement and utility of the internationalization.

Please continue to suggest other improvements, or even take a look at JIRA for some easier fixes or improvements. If you have trouble finding something to work on, please let me know!

Best regards!