DataNucleus JIRA is now in read-only mode. Raise any new issues in GitHub against the plugin that it applies to. DataNucleus JIRA will remain for the foreseeable future but will eventually be discontinued
Issue Details (XML | Word | Printable)

Type: Improvement Improvement
Status: Closed Closed
Resolution: Won't Fix
Priority: Trivial Trivial
Assignee: Unassigned
Reporter: Andrew Bourgeois
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
DataNucleus AccessPlatform


Created: 20/Oct/12 05:27 PM   Updated: 15/Nov/12 03:38 PM   Resolved: 24/Oct/12 05:05 PM
Component/s: Software
Affects Version/s: None
Fix Version/s: None

Severity: Production

 Description  « Hide
By using SLF4J we could use LOGBack and other logging frameworks.
Now when I'm using LOGBack (do you guys know that the creator of LOG4J moved to creating LOGBack years ago?), I still get to see java.util.Logging logs in my console.

Sort Order: Ascending order - Click to sort in descending order
Andy Jefferson added a comment - 24/Oct/12 05:05 PM - edited
You can already use SLF4j with "slf4j-log4j" as many other people have already done.

By not tying DataNucleus to *any* logging framework we allow all options. By hardcoding it to SLF4J it would impose a fixed requirement on any user to have to have SLF4J in the CLASSPATH and we don't want to do that.

Obviously if you wanted to use LogBack then you could contribute a wrapper to LogBack like the one for Log4J
and that way if the user has LogBack in their CLASSPATH it will be used. If you decide to take that option then raise an issue on NUCCORE and attach a patch for it

Either way I don't see SLF4J on the agenda.