[
https://issues.jboss.org/browse/JBLOGGING-57?page=com.atlassian.jira.plug...
]
Dan Allen commented on JBLOGGING-57:
------------------------------------
I just think it would be cleaner to have a single try/catch, but I guess that is a style
choice.
In general, though, the check for the class alone is really not sufficient, as you pointed
out. I think returning an incompatible version is itself a failure (enough to force the
use of the JDK14 logger). So I stick to my original guns and say that this logic is too
frail in it's current form. And that goes for even the slf4j and log4j checks
(assuming API incompatibilities are a possibility there too).
Logic for selecting a provider is too fragile
---------------------------------------------
Key: JBLOGGING-57
URL:
https://issues.jboss.org/browse/JBLOGGING-57
Project: JBoss Logging
Issue Type: Bug
Security Level: Public(Everyone can see)
Affects Versions: 3.0.0.Beta4-jboss-logging
Reporter: Dan Allen
Assignee: David Lloyd
Fix For: 3.0.0.Beta5-jboss-logging
The logic used to select the logging provider is too fragile. It should never throw an
exception while selecting a provider, because JDK logging is guaranteed to be available
and should be the fallback choice. When JBoss Logging fails to select a provider, it
causes deployment to fail, which violates my rule #1 of a logging framework (don't
fail a build because of a failure to setup logging).
The fragile logic is the reason we get JBLOGGING-47.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira