True, but if the exception is clear users will be able to fix the issue
themselves without needing to read the docs...
How about adding this constructor to
org.apache.logging.slf4j.SLF4JLoggerContext:
public SLF4JLoggerContext() {
// LOG4J2-204 (improve error reporting when misconfigured)
try {
Class.forName("org.slf4j.helpers.Log4JLoggerFactory");
throw new IllegalStateException("slf4j-impl jar is mutually
exclusive with log4j-to-slf4j jar " +
"(the first routes calls from SLF4J to Log4j, the second from
Log4j to SLF4J)");
} catch (Throwable classNotFoundIsGood) {
}
}
________________________________
From: Gary Gregory <[email protected]>
To: Log4J Developers List <[email protected]>
Sent: Wednesday, April 10, 2013 11:55 PM
Subject: Re: Maven Group Ids
And better documentation would help too :)
Gary
On Wed, Apr 10, 2013 at 10:46 AM, Nick Williams <[email protected]>
wrote:
I like that idea.
>
>Nick
>
>
>On Apr 10, 2013, at 9:43 AM, Remko Popma wrote:
>
>About the mutual exclusivity, would it be an idea to throw an exception from
>either log4j-slf4j-impl or log4j-to-slf4j when it detects that the other jar
>is on the classpath?
>>I just proposed a way to do that in
>>https://issues.apache.org/jira/browse/LOG4J2-204
>>
>>
>>
>>
>>
>>
>>
>>________________________________
>> From: Nick Williams <[email protected]>
>>To: Log4J Developers List <[email protected]>
>>Sent: Wednesday, April 10, 2013 11:37 PM
>>Subject: Re: Maven Group Ids
>>
>>
>>I'm guessing there's no way to tell Maven that two dependencies are mutually
>>exclusive and cannot both be used (for example, log4j-slf4j-impl and
>>log4j-to-slf4j)? Because that would be convenient...
>>
>>
>>Nick
>>
>>
>>On Apr 10, 2013, at 9:30 AM, Ralph Goers wrote:
>>
>>Well, I originally had them all in one groupId but it was suggested that they
>>be split to distinguish core functionality from the extra stuff. That did and
>>still does make sense to me, although using the groupId may not be the best
>>way to distinguish it. It might be done simply through a better web site
>>design. We have had a couple of users now include all the jars in their
>>project. The different groupIds hasn't stopped that. To be honest, I'm not
>>really sure what would.
>>>
>>>
>>>I have no problem switching back to a single groupId if that is the
>>>consensus, but we really need to lock that down as we can't be doing that
>>>after 2.0 GA is released.
>>>
>>>
>>>
>>>Ralph
>>>
>>>
>>>
>>>On Apr 10, 2013, at 6:21 AM, Gary Gregory wrote:
>>>
>>>Hi All:
>>>>
>>>>I find it confusing to have >1 group Id, for example in Ivy, when I tried
>>>>
>>>> <dependency org="org.apache.logging.log4j" name="log4j-api"
>>>>rev="2.0-beta4" />
>>>> <dependency org="org.apache.logging.log4j" name="log4j-core"
>>>>rev="2.0-beta4" />
>>>> <dependency org="org.apache.logging.log4j" name="log4j-1.2-api"
>>>>rev="2.0-beta4" />
>>>>
>>>>
>>>>it bombed because the 1.2 API is in "org.apache.logging.log4j.adapter" not
>>>>"org.apache.logging.log4j"
>>>>
>>>>
>>>>What is the point of this complication? It's bad enough we have a bunch of
>>>>jars, but multiple group ids?
>>>>
>>>>Gary
>>>>
>>>>
>>>>--
>>>>E-Mail: [email protected] | [email protected]
>>>>JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
>>>>Spring Batch in Action: http://bit.ly/bqpbCK
>>>>Blog: http://garygregory.wordpress.com
>>>>Home: http://garygregory.com/
>>>>Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>
--
E-Mail: [email protected] | [email protected]
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
