[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756535#comment-13756535
]
Nick Williams edited comment on LOG4J2-293 at 9/3/13 11:46 AM:
---------------------------------------------------------------
Point taken that there are improvements to be made on JavaDoc. However, there
are three separate issues here, and they all need to be handled differently:
# Log4j is not gracefully handling logging starting before Log4j's filter.
We're trying to fix that. This additional info you've provided is helpful to
get that straightened out. I definitely understand that silent failures are
frustrating.
# Something is starting logging before Log4j's filter. While Log4j should
handle this gracefully, this is still a *big problem* because you could be
missing important logging events. *I need more information to troubleshoot
this.* As mentioned above and above, I need A) your web.xml, B) your effective
web.xml as generated by Tomcat (the thread you linked to has instructions for
logging this info), and C) a list of any JARs in your webapp containing files
/META-INF/web-fragment.xml _OR_
META-INF/services/javax.servlet.ServletContainerInitializer.
# You are now getting an AbstractMethodError. I understand your frustration
with it, but Log4j cannot be responsible for detecting, catching, and reporting
all the many different errors that can happen because users have the wrong
versions of other-party libraries on their classpath. The error, as you pointed
out, means that you had an old Xerces on your classpath. Fixing that fixes the
problem. There's nothing that needs to be done in Log4j here.
was (Author: beamerblvd):
Point taken that there are improvements to be made on JavaDoc. However,
there are three separate issues here, and they all need to be handled
differently:
#. Log4j is not gracefully handling logging starting before Log4j's filter.
We're trying to fix that. This additional info you've provided is helpful to
get that straightened out. I definitely understand that silent failures are
frustrating.
#. Something is starting logging before Log4j's filter. While Log4j should
handle this gracefully, this is still a *big problem* because you could be
missing important logging events. *I need more information to troubleshoot
this.* As mentioned above and above, I need A) your web.xml, B) your effective
web.xml as generated by Tomcat (the thread you linked to has instructions for
logging this info), and C) a list of any JARs in your webapp containing files
/META-INF/web-fragment.xml _OR_
META-INF/services/javax.servlet.ServletContainerInitializer.
#. You are now getting an AbstractMethodError. I understand your frustration
with it, but Log4j cannot be responsible for detecting, catching, and reporting
all the many different errors that can happen because users have the wrong
versions of other-party libraries on their classpath. The error, as you pointed
out, means that you had an old Xerces on your classpath. Fixing that fixes the
problem. There's nothing that needs to be done in Log4j here.
> classloader URI scheme broken or insufficient when using Log4jContextListener
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-293
> URL: https://issues.apache.org/jira/browse/LOG4J2-293
> Project: Log4j 2
> Issue Type: Bug
> Components: Configurators
> Affects Versions: 2.0-beta7
> Reporter: Neale Upstone
> Assignee: Nick Williams
> Labels: documentation
> Fix For: 2.0-beta9
>
> Attachments: ConfigurationFactory.java, LOG4J2-293.patch,
> TestConfigurator.java
>
>
> I'm trying to migrate to Log4j2, and things looked promising when I spotted
> Log4jContextListener.
> However, there are too many holes.
> Firstly, I tried using classpath: as a scheme, and nothing blew up, so I
> assumed I'd got it right.
> Then I *looked at the code* (which shouldn't be how we find out) and
> eventually discovered some code relating to a 'classloader' scheme.
> Still silent failure. It seems that the classpath is not being searched,
> perhaps just the WAR classloader, not the JARs in WEB-INF/lib.
> Next I tried omitting the / (i.e. using classloader:log4j2.xml) and got a
> NullPointerException.
> Can you please document what schemes are supported and what you expect them
> to do, and *not fail silently* when a configuration file is specified, but
> nothing happens.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
