[jira] [Commented] (LOG4J2-599) Support lambda functions (or similar) for log message parameters
[
https://issues.apache.org/jira/browse/LOG4J2-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13964547#comment-13964547
]
Nick Williams commented on LOG4J2-599:
--
I would disagree with the notion that we are on Java 6. We're not _on_
anything. We _compile for_ Java 6—an end-of-life product with severe, unfixed
security vulnerabilities (such as the new Heartbleed vulnerability)—so that we
can provide backwards compatibility for people who shouldn't be using Java 6
anymore. That should in no way prevent us from providing tools that help those
using more modern JVMs. :-)
I suppose an alternative API for {{Callable}} could be:
{code:java}void ***(String message, CallableObject[] arguments);{code}
In Java 8, this would be fairly easy to use for simple and expensive arguments:
{code:java}logger.trace(Enter {} {} {} {}, (Callable)() - new Object[] {
argument1, argument2, argument3.someMethod(), argument4});{code}
However, we couldn't do the same thing for {{Supplier}} unless we compiled in
Java 8. The only way to support {{Supplier}} and maintain backwards
compatibility with Java 6 and 7 is to support it with {{Object...}}.
Support lambda functions (or similar) for log message parameters
Key: LOG4J2-599
URL: https://issues.apache.org/jira/browse/LOG4J2-599
Project: Log4j 2
Issue Type: Brainstorming
Components: Core
Reporter: Matt Sicker
Priority: Minor
It would be nice if we could support 0-param lambda functions (or the
equivalent: interfaces with a single empty-parameter message call), or more
simply, allow Runnables (or something similar) to be passed which will be
dynamically executed if the log message is enabled.
The use case here is that although string construction of the log message is
a performance issue that is already solved quite well, the problem of adding
in information to the log message that makes other calculations still needs
to be wrapped in an if check.
I'm not sure if it'd be best to just use Runnable, or create a new interface,
or try to emulate how Java 1.8 lambdas work via an interface with a single
method defined. The details here would still need to be fleshed out, but I
think this sort of feature could be rather handy (especially in a Java 1.8+
environment, or in Groovy/Scala/etc.).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-474) MongoDBProvider won't work with databases that don't have authentication set up
[
https://issues.apache.org/jira/browse/LOG4J2-474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-474:
Assignee: Nick Williams
MongoDBProvider won't work with databases that don't have authentication set
up
---
Key: LOG4J2-474
URL: https://issues.apache.org/jira/browse/LOG4J2-474
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta9
Reporter: Tal Liron
Assignee: Nick Williams
Attachments: MongoDbLog4jProvider.java
The problem is in line 178:
{code}
if (!database.isAuthenticated()) {
{code}
This assumes that isAuthenticated() returns true when authentication isn't
need. However, that is incorrect: databases without authentication configured
will return false here, in which case the provider will not be able to work
them.
I suggest simply removing this if (and also the else code from 183-187)
-- if authentication is required, errors will happen soon enough.
Unfortunately the MongoDB API doesn't let you know this until you try.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-474) MongoDBProvider won't work with databases that don't have authentication set up
[
https://issues.apache.org/jira/browse/LOG4J2-474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13911208#comment-13911208
]
Nick Williams commented on LOG4J2-474:
--
I'll take care of this, Tal. Thanks for contributing and for testing this
provider.
MongoDBProvider won't work with databases that don't have authentication set
up
---
Key: LOG4J2-474
URL: https://issues.apache.org/jira/browse/LOG4J2-474
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta9
Reporter: Tal Liron
Assignee: Nick Williams
Attachments: MongoDbLog4jProvider.java
The problem is in line 178:
{code}
if (!database.isAuthenticated()) {
{code}
This assumes that isAuthenticated() returns true when authentication isn't
need. However, that is incorrect: databases without authentication configured
will return false here, in which case the provider will not be able to work
them.
I suggest simply removing this if (and also the else code from 183-187)
-- if authentication is required, errors will happen soon enough.
Unfortunately the MongoDB API doesn't let you know this until you try.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-536) Project Depencies page has no content
[ https://issues.apache.org/jira/browse/LOG4J2-536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13899307#comment-13899307 ] Nick Williams commented on LOG4J2-536: -- H. This might be a Maven bug. The dependency CONVERGENCE page is fine: http://people.apache.org/~nickwilliams/log4j/dependency-convergence.html Remko asks a good question, though: What should go on this page? Project Depencies page has no content - Key: LOG4J2-536 URL: https://issues.apache.org/jira/browse/LOG4J2-536 Project: Log4j 2 Issue Type: Bug Components: Documentation Affects Versions: 2.0-rc1 Reporter: Gary Gregory While the Project Depencies page has no content, we clearly do have dependencies. See https://people.apache.org/~nickwilliams/log4j/dependencies.html I also built the site from the 2.0 RC1 rc2 src zip with the same results. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-529) Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
[
https://issues.apache.org/jira/browse/LOG4J2-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894616#comment-13894616
]
Nick Williams commented on LOG4J2-529:
--
Remko, here's your problem:
{code:xml}?xml version=1.0 encoding=ISO-8859-1?
web-app xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
version=2.4{code}
This is not a Servlet 3.0+ application. It's a Servlet 2.4 application. Doesn't
matter what the container version is—it'll ignore the
{{ServletContainerInitializer}}. The documentation clearly states this as well.
Please close as invalid.
Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on
undeploy
-
Key: LOG4J2-529
URL: https://issues.apache.org/jira/browse/LOG4J2-529
Project: Log4j 2
Issue Type: Bug
Components: Configurators, Core, JMX
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: Tomcat 7.0.50, Tomcat 8.0.1
Reporter: Remko Popma
Attachments: webapp1.war, webapp2.war
The log4j2 manuals
[says|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-3.0]
that Log4j 2 just works in Servlet 3.0 and newer web applications. It is
capable of automatically starting when the application deploys and shutting
down when the application undeploys.
When testing for LOG4J2-500, I found that this does not seem to be the case,
at least on Tomcat 7.0.50 and Tomcat 8.0.1.
*Steps to reproduce the issue*
# Enable JMX in Tomcat: create a file {{setup.bat}} in the {{bin}} directory
with the following contents: {{set
CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=54321
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false}}
# To test, I used the Tomcat [sample web
app|http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/], with the
following modifications:
#* add log4j-api-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* add log4j-core-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* put log4j2.xml in WEB-INF/classes. Any valid config with
{{status=trace}} should be sufficient.
#* copy hello.jsp to log.jsp and add these lines:
{code}
% org.apache.logging.log4j.Logger logger =
org.apache.logging.log4j.LogManager.getLogger(); %
% logger.info(Logging from JSP); %
%= new String(Hello! LOGGED FROM JSP OK.) %
{code}
# create {{webapp1.war}} from the above
# deploy webapp1. Note that in the Tomcat console you will only see INFO:
Deploying web application archive
D:\apps\apache-tomcat-7.0.50\webapps\webapp1.war, you will *not* see the
Log4J initialization status messages (like Generated plugins in 0.175750656
seconds, or Registering MBean org.apache.logging.log4j2:type=...)
# Open JConsole, and connect to localhost:54321. In the MBeans tab, you
will *not* see MBeans for {{org.apache.logging.log4j2}}.
# In a browser, open URL http://localhost:8080/webapp1/log.jsp
#* In the Tomcat console you should now see Generated plugins in 0.16172
seconds and Registering MBean org.apache.logging.log4j2
#* In JConsole you should now see MBeans for {{org.apache.logging.log4j2}}.
The LoggerContext name looks something like
{{org.apache.jasper.servlet.JasperLoader@7da612aa}}.
# Now, _undeploy_ webapp1.
#* *Bad sign #1:* in the Tomcat console I only see INFO: Undeploying context
/webapp1, I don't see any status messages for Log4J unloading. For example,
I don't see any Unregistering MBean ... messages.
#* *Bad sign #2:* in JConsole, the MBeans for {{org.apache.logging.log4j2}}
are still displayed. Accessing their attributes may cause errors in the
Tomcat console (INFO: Illegal access: this web application instance has been
stopped already. Could not load
sun.reflect.SerializationConstructorAccessorImpl. The eventual following
stack trace is caused by an error thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access, and has no
functional impact. java.lang.IllegalStateException...)
#* *Bad sign #3:* In the Tomcat manager app, pressing the Find Leaks button
shows this message: The following web applications were stopped (reloaded,
undeployed), but their classes from previous runs are still loaded in memory,
thus causing a memory leak (use a profiler to confirm): /webapp1
So with the default setup, undeploying a webapp with log4j2 in its
WEB-INF/lib folder does not automatically call {{LoggerContext.stop()}}.
Things do seem to work better if I modify the {{web.xml}} file and add the
listener, filter and filter-mapping [recommended for Servlet 2.5 web
[jira] [Commented] (LOG4J2-529) Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
[
https://issues.apache.org/jira/browse/LOG4J2-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894841#comment-13894841
]
Nick Williams commented on LOG4J2-529:
--
I still can't duplicate this. I downloaded the webapp30.war file attached to
this issue, deployed it in Tomcat 8.0.1, saw the Log4j debug statements
immediately, opened JConsole, and there are the MBeans. I never even opened the
browser. It appears to work perfectly.
Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on
undeploy
-
Key: LOG4J2-529
URL: https://issues.apache.org/jira/browse/LOG4J2-529
Project: Log4j 2
Issue Type: Bug
Components: Configurators, Core, JMX
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: Tomcat 7.0.50, Tomcat 8.0.1
Reporter: Remko Popma
Attachments: webapp2.war, webapp30-listener.war, webapp30.war
The log4j2 manuals
[says|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-3.0]
that Log4j 2 just works in Servlet 3.0 and newer web applications. It is
capable of automatically starting when the application deploys and shutting
down when the application undeploys.
When testing for LOG4J2-500, I found that this does not seem to be the case,
at least on Tomcat 7.0.50 and Tomcat 8.0.1.
*Steps to reproduce the issue*
# Enable JMX in Tomcat: create a file {{setup.bat}} in the {{bin}} directory
with the following contents: {{set
CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=54321
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false}}
# To test, I used the Tomcat [sample web
app|http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/], with the
following modifications:
#* add log4j-api-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* add log4j-core-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* put log4j2.xml in WEB-INF/classes. Any valid config with
{{status=trace}} should be sufficient.
#* copy hello.jsp to log.jsp and add these lines:
{code}
% org.apache.logging.log4j.Logger logger =
org.apache.logging.log4j.LogManager.getLogger(); %
% logger.info(Logging from JSP); %
%= new String(Hello! LOGGED FROM JSP OK.) %
{code}
# create {{webapp1.war}} from the above
# deploy webapp1. Note that in the Tomcat console you will only see INFO:
Deploying web application archive
D:\apps\apache-tomcat-7.0.50\webapps\webapp1.war, you will *not* see the
Log4J initialization status messages (like Generated plugins in 0.175750656
seconds, or Registering MBean org.apache.logging.log4j2:type=...)
# Open JConsole, and connect to localhost:54321. In the MBeans tab, you
will *not* see MBeans for {{org.apache.logging.log4j2}}.
# In a browser, open URL http://localhost:8080/webapp1/log.jsp
#* In the Tomcat console you should now see Generated plugins in 0.16172
seconds and Registering MBean org.apache.logging.log4j2
#* In JConsole you should now see MBeans for {{org.apache.logging.log4j2}}.
The LoggerContext name looks something like
{{org.apache.jasper.servlet.JasperLoader@7da612aa}}.
# Now, _undeploy_ webapp1.
#* *Bad sign #1:* in the Tomcat console I only see INFO: Undeploying context
/webapp1, I don't see any status messages for Log4J unloading. For example,
I don't see any Unregistering MBean ... messages.
#* *Bad sign #2:* in JConsole, the MBeans for {{org.apache.logging.log4j2}}
are still displayed. Accessing their attributes may cause errors in the
Tomcat console (INFO: Illegal access: this web application instance has been
stopped already. Could not load
sun.reflect.SerializationConstructorAccessorImpl. The eventual following
stack trace is caused by an error thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access, and has no
functional impact. java.lang.IllegalStateException...)
#* *Bad sign #3:* In the Tomcat manager app, pressing the Find Leaks button
shows this message: The following web applications were stopped (reloaded,
undeployed), but their classes from previous runs are still loaded in memory,
thus causing a memory leak (use a profiler to confirm): /webapp1
So with the default setup, undeploying a webapp with log4j2 in its
WEB-INF/lib folder does not automatically call {{LoggerContext.stop()}}.
Things do seem to work better if I modify the {{web.xml}} file and add the
listener, filter and filter-mapping [recommended for Servlet 2.5 web
applications|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-2.5].
# create webapp2.war with the modified {{web.xml}} file
# shutdown and startup Tomcat/7.0.50
# deploy webapp2.war. *_Do not open log.jsp in a browser yet._* In this case
I immediately see Log4J
[jira] [Commented] (LOG4J2-529) Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
[
https://issues.apache.org/jira/browse/LOG4J2-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894853#comment-13894853
]
Nick Williams commented on LOG4J2-529:
--
I just tried a different approach and it still worked. I've been dumping the
WAR file in {{webapps}} and then starting Tomcat. This time I started Tomcat
and then used the manager console to deploy the WAR file _after_ Tomcat starts.
No difference: I still see the Log4j debug statements immediately, and JConsole
(which didn't show the Log4j MBeans before I deployed the application) suddenly
updates to show the MBeans. Never opened the browser.
I'm just not seeing a problem here, Remko.
Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on
undeploy
-
Key: LOG4J2-529
URL: https://issues.apache.org/jira/browse/LOG4J2-529
Project: Log4j 2
Issue Type: Bug
Components: Configurators, Core, JMX
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: Tomcat 7.0.50, Tomcat 8.0.1
Reporter: Remko Popma
Attachments: webapp2.war, webapp30-listener.war, webapp30.war
The log4j2 manuals
[says|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-3.0]
that Log4j 2 just works in Servlet 3.0 and newer web applications. It is
capable of automatically starting when the application deploys and shutting
down when the application undeploys.
When testing for LOG4J2-500, I found that this does not seem to be the case,
at least on Tomcat 7.0.50 and Tomcat 8.0.1.
*Steps to reproduce the issue*
# Enable JMX in Tomcat: create a file {{setup.bat}} in the {{bin}} directory
with the following contents: {{set
CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=54321
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false}}
# To test, I used the Tomcat [sample web
app|http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/], with the
following modifications:
#* add log4j-api-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* add log4j-core-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* put log4j2.xml in WEB-INF/classes. Any valid config with
{{status=trace}} should be sufficient.
#* copy hello.jsp to log.jsp and add these lines:
{code}
% org.apache.logging.log4j.Logger logger =
org.apache.logging.log4j.LogManager.getLogger(); %
% logger.info(Logging from JSP); %
%= new String(Hello! LOGGED FROM JSP OK.) %
{code}
# create {{webapp1.war}} from the above
# deploy webapp1. Note that in the Tomcat console you will only see INFO:
Deploying web application archive
D:\apps\apache-tomcat-7.0.50\webapps\webapp1.war, you will *not* see the
Log4J initialization status messages (like Generated plugins in 0.175750656
seconds, or Registering MBean org.apache.logging.log4j2:type=...)
# Open JConsole, and connect to localhost:54321. In the MBeans tab, you
will *not* see MBeans for {{org.apache.logging.log4j2}}.
# In a browser, open URL http://localhost:8080/webapp1/log.jsp
#* In the Tomcat console you should now see Generated plugins in 0.16172
seconds and Registering MBean org.apache.logging.log4j2
#* In JConsole you should now see MBeans for {{org.apache.logging.log4j2}}.
The LoggerContext name looks something like
{{org.apache.jasper.servlet.JasperLoader@7da612aa}}.
# Now, _undeploy_ webapp1.
#* *Bad sign #1:* in the Tomcat console I only see INFO: Undeploying context
/webapp1, I don't see any status messages for Log4J unloading. For example,
I don't see any Unregistering MBean ... messages.
#* *Bad sign #2:* in JConsole, the MBeans for {{org.apache.logging.log4j2}}
are still displayed. Accessing their attributes may cause errors in the
Tomcat console (INFO: Illegal access: this web application instance has been
stopped already. Could not load
sun.reflect.SerializationConstructorAccessorImpl. The eventual following
stack trace is caused by an error thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access, and has no
functional impact. java.lang.IllegalStateException...)
#* *Bad sign #3:* In the Tomcat manager app, pressing the Find Leaks button
shows this message: The following web applications were stopped (reloaded,
undeployed), but their classes from previous runs are still loaded in memory,
thus causing a memory leak (use a profiler to confirm): /webapp1
So with the default setup, undeploying a webapp with log4j2 in its
WEB-INF/lib folder does not automatically call {{LoggerContext.stop()}}.
Things do seem to work better if I modify the {{web.xml}} file and add the
listener, filter and filter-mapping [recommended for Servlet 2.5 web
[jira] [Commented] (LOG4J2-529) Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
[
https://issues.apache.org/jira/browse/LOG4J2-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894889#comment-13894889
]
Nick Williams commented on LOG4J2-529:
--
Yes, {{webapp30.war}} won't work in Tomcat 7.0.40 because of a bug in Tomcat.
The Log4j documentation says you have to remove {{log4j*.jar}} from
{{jarsToSkip}} in {{catalina.properties}} until Tomcat 7.0.43, when the bug was
fixed.
Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on
undeploy
-
Key: LOG4J2-529
URL: https://issues.apache.org/jira/browse/LOG4J2-529
Project: Log4j 2
Issue Type: Bug
Components: Configurators, Core, JMX
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: Tomcat 7.0.50, Tomcat 8.0.1
Reporter: Remko Popma
Attachments: webapp2.war, webapp30-listener.war, webapp30.war
The log4j2 manuals
[says|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-3.0]
that Log4j 2 just works in Servlet 3.0 and newer web applications. It is
capable of automatically starting when the application deploys and shutting
down when the application undeploys.
When testing for LOG4J2-500, I found that this does not seem to be the case,
at least on Tomcat 7.0.50 and Tomcat 8.0.1.
*Steps to reproduce the issue*
# Enable JMX in Tomcat: create a file {{setup.bat}} in the {{bin}} directory
with the following contents: {{set
CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=54321
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false}}
# To test, I used the Tomcat [sample web
app|http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/], with the
following modifications:
#* add log4j-api-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* add log4j-core-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* put log4j2.xml in WEB-INF/classes. Any valid config with
{{status=trace}} should be sufficient.
#* copy hello.jsp to log.jsp and add these lines:
{code}
% org.apache.logging.log4j.Logger logger =
org.apache.logging.log4j.LogManager.getLogger(); %
% logger.info(Logging from JSP); %
%= new String(Hello! LOGGED FROM JSP OK.) %
{code}
# create {{webapp1.war}} from the above
# deploy webapp1. Note that in the Tomcat console you will only see INFO:
Deploying web application archive
D:\apps\apache-tomcat-7.0.50\webapps\webapp1.war, you will *not* see the
Log4J initialization status messages (like Generated plugins in 0.175750656
seconds, or Registering MBean org.apache.logging.log4j2:type=...)
# Open JConsole, and connect to localhost:54321. In the MBeans tab, you
will *not* see MBeans for {{org.apache.logging.log4j2}}.
# In a browser, open URL http://localhost:8080/webapp1/log.jsp
#* In the Tomcat console you should now see Generated plugins in 0.16172
seconds and Registering MBean org.apache.logging.log4j2
#* In JConsole you should now see MBeans for {{org.apache.logging.log4j2}}.
The LoggerContext name looks something like
{{org.apache.jasper.servlet.JasperLoader@7da612aa}}.
# Now, _undeploy_ webapp1.
#* *Bad sign #1:* in the Tomcat console I only see INFO: Undeploying context
/webapp1, I don't see any status messages for Log4J unloading. For example,
I don't see any Unregistering MBean ... messages.
#* *Bad sign #2:* in JConsole, the MBeans for {{org.apache.logging.log4j2}}
are still displayed. Accessing their attributes may cause errors in the
Tomcat console (INFO: Illegal access: this web application instance has been
stopped already. Could not load
sun.reflect.SerializationConstructorAccessorImpl. The eventual following
stack trace is caused by an error thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access, and has no
functional impact. java.lang.IllegalStateException...)
#* *Bad sign #3:* In the Tomcat manager app, pressing the Find Leaks button
shows this message: The following web applications were stopped (reloaded,
undeployed), but their classes from previous runs are still loaded in memory,
thus causing a memory leak (use a profiler to confirm): /webapp1
So with the default setup, undeploying a webapp with log4j2 in its
WEB-INF/lib folder does not automatically call {{LoggerContext.stop()}}.
Things do seem to work better if I modify the {{web.xml}} file and add the
listener, filter and filter-mapping [recommended for Servlet 2.5 web
applications|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-2.5].
# create webapp2.war with the modified {{web.xml}} file
# shutdown and startup Tomcat/7.0.50
# deploy webapp2.war. *_Do not open log.jsp in a browser yet._* In this case
I immediately see Log4J initialization status messages like
[jira] [Closed] (LOG4J2-422) DriverManager for JDBC Appender should have argument for explicit Driver class
[ https://issues.apache.org/jira/browse/LOG4J2-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams closed LOG4J2-422. Closing because not an issue anymore. DriverManager for JDBC Appender should have argument for explicit Driver class -- Key: LOG4J2-422 URL: https://issues.apache.org/jira/browse/LOG4J2-422 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-beta9 Reporter: erich oliphant Assignee: Nick Williams Fix For: 2.0-rc1 I had a situation where the DriverManager was unable to properly load the jdbc driver (Oracle) via url resolution alone. The DriverManager doesnt' currently allow you to explicitly specify the the driver. I resolved my situation by creating my own that accepts a driver parameter, but it seems like this should be added to the core -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-422) DriverManager for JDBC Appender should have argument for explicit Driver class
[
https://issues.apache.org/jira/browse/LOG4J2-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-422.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
This issue is fixed with r1565838. However, the fix does not actually fix the
{{DriverManager...}} connection source plugin—it removes it. This plugin is
not safe and can't use a connection pool. Starting with rc1 you will need to
either use the {{DataSource...}} or {{ConnectionFactory...}} connection
source plugins, instead, and they should be backed with a connection pool. The
updated site documentation will explain this further once rc1 is released.
DriverManager for JDBC Appender should have argument for explicit Driver class
--
Key: LOG4J2-422
URL: https://issues.apache.org/jira/browse/LOG4J2-422
Project: Log4j 2
Issue Type: Improvement
Components: Appenders
Affects Versions: 2.0-beta9
Reporter: erich oliphant
Assignee: Nick Williams
Fix For: 2.0-rc1
I had a situation where the DriverManager was unable to properly load the
jdbc driver (Oracle) via url resolution alone. The DriverManager doesnt'
currently allow you to explicitly specify the the driver. I resolved my
situation by creating my own that accepts a driver parameter, but it seems
like this should be added to the core
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-442:
Assignee: Nick Williams
Log4j2 Database insert problem in Websphere
---
Key: LOG4J2-442
URL: https://issues.apache.org/jira/browse/LOG4J2-442
Project: Log4j 2
Issue Type: Bug
Components: Appenders, Configurators
Affects Versions: 2.0-beta8
Environment: Java Web Service in Websphere server
Reporter: Barış Taşkend
Assignee: Nick Williams
Priority: Blocker
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
?xml version=1.0 encoding=UTF-8?
configuration status=OFF
appenders
!-- Async Loggers will auto-flush in batches, so switch off
immediateFlush. --
FastFile name=AsyncFastFile fileName=${sys:logFilename}
immediateFlush=false append=true
PatternLayout
patterntest %m %m %ex%n/pattern
/PatternLayout
/FastFile
JDBC name=databaseAppender tableName=mytablename
DriverManager
url=jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME /
Column name=KEY1 pattern=%X{sayi1} /
Column name=KEY2 pattern=%X{sayi2} /
/JDBC
JDBC name=databaseAppenderJNDI tableName=mytablename
DataSource jndiName=java:/comp/env/jdbc/logWS /
Column name=KEY1 pattern=%X{sayi1} /
Column name=KEY2 pattern=%X{sayi2} /
/JDBC
/appenders
loggers
!-- pattern layout actually uses location, so we need to include it
--
asyncLogger name=ASYNC level=TRACE additivity=false
appender-ref ref=databaseAppender/
/asyncLogger
!-- pattern layout actually uses location, so we need to include it --
asyncLogger name=ASYNCwithJNDI level=TRACE additivity=false
appender-ref ref=databaseAppenderJNDI/
/asyncLogger
root level=info includeLocation=true
appender-ref ref=databaseAppender/
/root
/loggers
/configuration
{code}
I can insert logs to text file and DB by switching loggername in my java
class which I call log function. There no problem in my local.
In Webshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't
insert logs to database. I tried both driverManager url and JNDI. But nothing
changed. In two ways, I can't insert log to DB and program doesn't throw any
error in try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in webshere. Also I can
insert log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How can I solve this problem?
THX.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-489) Should JPADatabaseManager being using so many transactions?
[ https://issues.apache.org/jira/browse/LOG4J2-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams reassigned LOG4J2-489: Assignee: Nick Williams Should JPADatabaseManager being using so many transactions? --- Key: LOG4J2-489 URL: https://issues.apache.org/jira/browse/LOG4J2-489 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0 Environment: JPA appender Reporter: Matt Sicker Assignee: Nick Williams Priority: Minor Labels: Appender, JPA, Performance, Transaction Even when the appender is buffered, every log event is still committed each time. In JDBCAppender, when it's buffered, log events aren't inserted into the database until the buffer is full. I tried to address this while I was working on another patch, but there's no good way to generate an EntityTransaction without the EntityManager, and that's recreated each time writeInternal() is called. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-457) JDBCAppender does not release JDBC connections to the connection pool when WAR/EAR is stopped
[ https://issues.apache.org/jira/browse/LOG4J2-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams reassigned LOG4J2-457: Assignee: Nick Williams JDBCAppender does not release JDBC connections to the connection pool when WAR/EAR is stopped - Key: LOG4J2-457 URL: https://issues.apache.org/jira/browse/LOG4J2-457 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.0-beta9 Environment: JBOSS application server, PostgreSQL database Reporter: Tihomir Meščić Assignee: Nick Williams We use log4j 2 for logging inside our J2EE app (packaged as EAR, log4j JARs are bundled inside). The app is deployed on JBOSS EAP 6.1 app server. We are using the JDBCAppender for logging to a PostgreSQL database, and the appender is configured to use a DataSource for fetching connections. The appender is configured as follows: JDBC name=jdbcAppender tableName=log_entries DataSource jndiName=java:jboss/datasources/XyzDS / Column name=log_entries_message isUnicode=false pattern=%message / Column name=log_entries_type literal=0 / . The problem is: after the EAR is stopped (undeployed) log4j is not releasing the JDBC connection back to the connection pool, and after we stop/start the application a couple of times, our server becomes useless because there are no more free connections in the connection pool. I've looked at the thread dump of the server and there are a lot of threads like this: org.apache.logging.log4j.core.LoggerContext$ShutdownThread @ 0xbe447138 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-438) JDBCDatabaseManager does not send commit command
[
https://issues.apache.org/jira/browse/LOG4J2-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-438.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1565858 and r1565878. The database appenders now connect to the
database (i.e., borrow from the connection pool) and begin a transaction on
every flush or every non-buffered {{writeInternal}}, then commit and disconnect
(i.e., return to pool) at the end of the flush or non-buffered
{{writeInternal}}.
Note also that the {{DriverManager...}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{DataSource...}} or {{ConnectionFactory...}}
connection source plugins, instead.
JDBCDatabaseManager does not send commit command
Key: LOG4J2-438
URL: https://issues.apache.org/jira/browse/LOG4J2-438
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta9
Environment: Java 7u45, Windows, H2
Reporter: Ralph Schaer
Assignee: Nick Williams
Priority: Minor
Fix For: 2.0-rc1
Attachments: 0001-Add-transaction-wrapper.patch,
0002-Add-transaction-support-for-AbstractDatabaseManager.patch
I'm fiddling with the log4j jdbc appender and found an issue with datasources
that have the flag defaultAutoCommit set to false. With such datasources the
application has to call the method connection.commit() after an update
statement, if omitted nothing will be updated or inserted in the database.
That is the problem with the class JDBCDatabaseManager. It executes the
statement (with this.statement.executeUpdate()) but does not call commit.
Nothing is inserted if the defaultAutoCommit flag of the datasource is set to
false.
One possible solution is to check the autoCommit flag of the datasource and
call commit when it's set to false.
if (this.statement.executeUpdate() == 0) {
throw new AppenderLoggingException(
No records inserted in database table for log event in JDBC manager.);
}
if (!this.connection.getAutoCommit()) {
this.connection.commit();
}
Maybe this has to be done differently when a buffer is used. The method
AbstractDatabaseManager.flush should only call commit after the loop.
if (this.isConnected() this.buffer.size() 0) {
for (final LogEvent event : this.buffer) {
this.writeInternal(event);
}
if (!connection.getAutoCommit()) {
connection.commit();
}
this.buffer.clear();
}
Or maybe using the batch methods of jdbc would improve the performance even
more
if (this.isConnected() this.buffer.size() 0) {
for (final LogEvent event : this.buffer) {
//create statement ...
statement.addBatch()
}
statement.executeBatch();
if (!connection.getAutoCommit()) {
connection.commit();
}
this.buffer.clear();
}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-407) JDBCAppender cannot recover from loss of database connectivity
[
https://issues.apache.org/jira/browse/LOG4J2-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-407.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1565858 and r1565878. The database appenders now connect to the
database (i.e., borrow from the connection pool) and begin a transaction on
every flush or every non-buffered {{writeInternal}}, then commit and disconnect
(i.e., return to pool) at the end of the flush or non-buffered
{{writeInternal}}.
Note also that the {{DriverManager...}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{DataSource...}} or {{ConnectionFactory...}}
connection source plugins, instead.
JDBCAppender cannot recover from loss of database connectivity
--
Key: LOG4J2-407
URL: https://issues.apache.org/jira/browse/LOG4J2-407
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta9
Reporter: Michael Kloster
Assignee: Nick Williams
Fix For: 2.0-rc1
The JDBCAppender holds a single database connection for all its logging. If
that database connection is closed, it does not attempt to make a new
connection.
Many connection pools automatically close connections after a certain amount
of inactivity. (This can be worked around by properly configuring a pool).
Database connectivity issues are also common enough that a long running
application may experience temporary network issues. When the network comes
back online, the logging will not resume.
I've been meaning to submit a patch for this, but I haven't gotten to it.
Since I saw that you are looking to come out of beta soon, I thought I would
log this issue in case someone else has time to write the patch before I get
to it.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-442) Log4j2 Database insert problem in Websphere
[
https://issues.apache.org/jira/browse/LOG4J2-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-442.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1565858 and r1565878. The database appenders now connect to the
database (i.e., borrow from the connection pool) and begin a transaction on
every flush or every non-buffered {{writeInternal}}, then commit and disconnect
(i.e., return to pool) at the end of the flush or non-buffered
{{writeInternal}}.
Note also that the {{DriverManager...}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{DataSource...}} or {{ConnectionFactory...}}
connection source plugins, instead.
Log4j2 Database insert problem in Websphere
---
Key: LOG4J2-442
URL: https://issues.apache.org/jira/browse/LOG4J2-442
Project: Log4j 2
Issue Type: Bug
Components: Appenders, Configurators
Affects Versions: 2.0-beta8
Environment: Java Web Service in Websphere server
Reporter: Barış Taşkend
Assignee: Nick Williams
Priority: Blocker
Fix For: 2.0-rc1
In my local,
I created an log4j2.xml to config like that :
{code:title=log4j2.xml|borderStyle=solid}
?xml version=1.0 encoding=UTF-8?
configuration status=OFF
appenders
!-- Async Loggers will auto-flush in batches, so switch off
immediateFlush. --
FastFile name=AsyncFastFile fileName=${sys:logFilename}
immediateFlush=false append=true
PatternLayout
patterntest %m %m %ex%n/pattern
/PatternLayout
/FastFile
JDBC name=databaseAppender tableName=mytablename
DriverManager
url=jdbc:oracle:thin:ORCL_USERNAME/PASS@//MYSERVERNAME:PORTNO/DBNAME /
Column name=KEY1 pattern=%X{sayi1} /
Column name=KEY2 pattern=%X{sayi2} /
/JDBC
JDBC name=databaseAppenderJNDI tableName=mytablename
DataSource jndiName=java:/comp/env/jdbc/logWS /
Column name=KEY1 pattern=%X{sayi1} /
Column name=KEY2 pattern=%X{sayi2} /
/JDBC
/appenders
loggers
!-- pattern layout actually uses location, so we need to include it
--
asyncLogger name=ASYNC level=TRACE additivity=false
appender-ref ref=databaseAppender/
/asyncLogger
!-- pattern layout actually uses location, so we need to include it --
asyncLogger name=ASYNCwithJNDI level=TRACE additivity=false
appender-ref ref=databaseAppenderJNDI/
/asyncLogger
root level=info includeLocation=true
appender-ref ref=databaseAppender/
/root
/loggers
/configuration
{code}
I can insert logs to text file and DB by switching loggername in my java
class which I call log function. There no problem in my local.
In Webshere server,
I call a web service for logging. I am using same config file and same java
codes which calls log function. I can insert logs to a file but I can't
insert logs to database. I tried both driverManager url and JNDI. But nothing
changed. In two ways, I can't insert log to DB and program doesn't throw any
error in try-catch. So I can't find problem where is.
Note : There is no problem at JNDI url and drivermanager url. Because I can
perfectly use these urls in different webservice in webshere. Also I can
insert log to Database in my local with same codes.
Note : There is no problem to insert logs to txt file. only DB insertion is
problem in Websphere server. So there isn't problem at config file classpath.
For your info, I am using oracle DB but the problem isn't about DB.
I trace network packages in server and I realize that web service don't send
any package to DB. Packages don't reach to DB.
How can I solve this problem?
THX.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-489) Should JPADatabaseManager being using so many transactions?
[
https://issues.apache.org/jira/browse/LOG4J2-489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-489.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1565858 and r1565878. The database appenders now connect to the
database (i.e., borrow from the connection pool) and begin a transaction on
every flush or every non-buffered {{writeInternal}}, then commit and disconnect
(i.e., return to pool) at the end of the flush or non-buffered
{{writeInternal}}.
Note also that the {{DriverManager...}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{DataSource...}} or {{ConnectionFactory...}}
connection source plugins, instead.
Should JPADatabaseManager being using so many transactions?
---
Key: LOG4J2-489
URL: https://issues.apache.org/jira/browse/LOG4J2-489
Project: Log4j 2
Issue Type: Improvement
Components: Appenders
Affects Versions: 2.0
Environment: JPA appender
Reporter: Matt Sicker
Assignee: Nick Williams
Priority: Minor
Labels: Appender, JPA, Performance, Transaction
Fix For: 2.0-rc1
Even when the appender is buffered, every log event is still committed each
time. In JDBCAppender, when it's buffered, log events aren't inserted into
the database until the buffer is full.
I tried to address this while I was working on another patch, but there's no
good way to generate an EntityTransaction without the EntityManager, and
that's recreated each time writeInternal() is called.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-457) JDBCAppender does not release JDBC connections to the connection pool when WAR/EAR is stopped
[
https://issues.apache.org/jira/browse/LOG4J2-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-457.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1565858 and r1565878. The database appenders now connect to the
database (i.e., borrow from the connection pool) and begin a transaction on
every flush or every non-buffered {{writeInternal}}, then commit and disconnect
(i.e., return to pool) at the end of the flush or non-buffered
{{writeInternal}}.
Note also that the {{DriverManager...}} connection source plugin is no longer
available. It was removed because it was unsafe and didn't support connection
pooling. Please use the {{DataSource...}} or {{ConnectionFactory...}}
connection source plugins, instead.
JDBCAppender does not release JDBC connections to the connection pool when
WAR/EAR is stopped
-
Key: LOG4J2-457
URL: https://issues.apache.org/jira/browse/LOG4J2-457
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta9
Environment: JBOSS application server, PostgreSQL database
Reporter: Tihomir Meščić
Assignee: Nick Williams
Fix For: 2.0-rc1
We use log4j 2 for logging inside our J2EE app (packaged as EAR, log4j JARs
are bundled inside). The app is deployed on JBOSS EAP 6.1 app server. We are
using the JDBCAppender for logging to a PostgreSQL database, and the appender
is configured to use a DataSource for fetching connections. The appender is
configured as follows:
JDBC name=jdbcAppender tableName=log_entries
DataSource jndiName=java:jboss/datasources/XyzDS /
Column name=log_entries_message isUnicode=false pattern=%message
/
Column name=log_entries_type literal=0 /
.
The problem is: after the EAR is stopped (undeployed) log4j is not releasing
the JDBC connection back to the connection pool, and after we stop/start the
application a couple of times, our server becomes useless because there are
no more free connections in the connection pool. I've looked at the thread
dump of the server and there are a lot of threads like this:
org.apache.logging.log4j.core.LoggerContext$ShutdownThread @ 0xbe447138
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-475) MongoDBConnection is broken because it uses addDecodingHook instead of addEncodingHook
[ https://issues.apache.org/jira/browse/LOG4J2-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams reassigned LOG4J2-475: Assignee: Nick Williams MongoDBConnection is broken because it uses addDecodingHook instead of addEncodingHook -- Key: LOG4J2-475 URL: https://issues.apache.org/jira/browse/LOG4J2-475 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.0-beta9 Reporter: Tal Liron Assignee: Nick Williams Attachments: 0001-Fix-LOG4J2-475.patch Seems trivial to fix, just use addEncodingHook. (I have a feeling MongoDB logging has never been tested! Is there a unit test for it?) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-475) MongoDBConnection is broken because it uses addDecodingHook instead of addEncodingHook
[ https://issues.apache.org/jira/browse/LOG4J2-475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams resolved LOG4J2-475. -- Resolution: Fixed Fix Version/s: 2.0-rc1 Fixed with r1565889. Based it off of Matt's patch, but there's no need to also have a decoding hook because the appender doesn't read events, it only writes them. MongoDBConnection is broken because it uses addDecodingHook instead of addEncodingHook -- Key: LOG4J2-475 URL: https://issues.apache.org/jira/browse/LOG4J2-475 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.0-beta9 Reporter: Tal Liron Assignee: Nick Williams Fix For: 2.0-rc1 Attachments: 0001-Fix-LOG4J2-475.patch Seems trivial to fix, just use addEncodingHook. (I have a feeling MongoDB logging has never been tested! Is there a unit test for it?) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-444) Log4j2 eclipselink integration
[
https://issues.apache.org/jira/browse/LOG4J2-444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-444.
--
Resolution: Not A Problem
Assignee: Nick Williams
According to the [EclipseLink logging
documentation|http://wiki.eclipse.org/EclipseLink/Foundation/Logging#Using_Log4J],
you just need to make sure Commons Logging 1.1.x and the Log4j 2 Commons
Logging Bridge (Maven artifact log4j-jcl) are on your classpath and add the
following property to your persistence unit:
{code:xml}property name=eclipselink.logging.logger
value=org.eclipse.persistence.logging.CommonsLoggingSessionLog/{code}
Log4j2 eclipselink integration
--
Key: LOG4J2-444
URL: https://issues.apache.org/jira/browse/LOG4J2-444
Project: Log4j 2
Issue Type: Question
Affects Versions: 2.0-beta9
Reporter: Mickael Hemri
Assignee: Nick Williams
Hi everyone,
I wanted to know If someone knows a way to integrate eclipselink logger with
log4j2. I try to do it myself but I didn't succeed.
Thanks !
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-529) Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on undeploy
[
https://issues.apache.org/jira/browse/LOG4J2-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13894172#comment-13894172
]
Nick Williams commented on LOG4J2-529:
--
Remko, I can't reproduce it. Works fine for me in Tomcat 8.0.1. Now, I haven't
tested 7.0.50 yet because I don't have it installed. But since it works for me
in Tomcat 8.0.1 and not for you, I think it's safe to focus on that for right
now.
In Tomcat 8.0.1, the Log4jServletContainerInitializer is called (I put a
breakpoint in there to confirm), the listener and filter are registered and
initialized (also confirmed with breakpoint), and the MBeans are registered
(they're showing up in JConsole).
I'm not sure what to do next...
Can you show me your deployment descriptor (sans the listener and filter
configurations)?
Log4j2 does not auto-initialize on webapp deploy or auto-deinitialize on
undeploy
-
Key: LOG4J2-529
URL: https://issues.apache.org/jira/browse/LOG4J2-529
Project: Log4j 2
Issue Type: Bug
Components: Configurators, Core, JMX
Affects Versions: 2.0-beta9, 2.0-rc1
Environment: Tomcat 7.0.50, Tomcat 8.0.1
Reporter: Remko Popma
The log4j2 manuals
[says|http://logging.apache.org/log4j/2.0/manual/webapp.html#Servlet-3.0]
that Log4j 2 just works in Servlet 3.0 and newer web applications. It is
capable of automatically starting when the application deploys and shutting
down when the application undeploys.
When testing for LOG4J2-500, I found that this does not seem to be the case,
at least on Tomcat 7.0.50 and Tomcat 8.0.1.
*Steps to reproduce the issue*
# Enable JMX in Tomcat: create a file {{setup.bat}} in the {{bin}} directory
with the following contents: {{set
CATALINA_OPTS=-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=54321
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false}}
# To test, I used the Tomcat [sample web
app|http://tomcat.apache.org/tomcat-6.0-doc/appdev/sample/], with the
following modifications:
#* add log4j-api-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* add log4j-core-2.0RC1-SNAPSHOT.jar to WEB-INF/lib
#* put log4j2.xml in WEB-INF/classes. Any valid config with
{{status=trace}} should be sufficient.
#* copy hello.jsp to log.jsp and add these lines:
{code}
% org.apache.logging.log4j.Logger logger =
org.apache.logging.log4j.LogManager.getLogger(); %
% logger.info(Logging from JSP); %
%= new String(Hello! LOGGED FROM JSP OK.) %
{code}
# create {{webapp1.war}} from the above
# deploy webapp1. Note that in the Tomcat console you will only see INFO:
Deploying web application archive
D:\apps\apache-tomcat-7.0.50\webapps\webapp1.war, you will *not* see the
Log4J initialization status messages (like Generated plugins in 0.175750656
seconds, or Registering MBean org.apache.logging.log4j2:type=...)
# Open JConsole, and connect to localhost:54321. In the MBeans tab, you
will *not* see MBeans for {{org.apache.logging.log4j2}}.
# In a browser, open URL http://localhost:8080/webapp1/log.jsp
#* In the Tomcat console you should now see Generated plugins in 0.16172
seconds and Registering MBean org.apache.logging.log4j2
#* In JConsole you should now see MBeans for {{org.apache.logging.log4j2}}.
The LoggerContext name looks something like
{{org.apache.jasper.servlet.JasperLoader@7da612aa}}.
# Now, _undeploy_ webapp1.
#* *Bad sign #1:* in the Tomcat console I only see INFO: Undeploying context
/webapp1, I don't see any status messages for Log4J unloading. For example,
I don't see any Unregistering MBean ... messages.
#* *Bad sign #2:* in JConsole, the MBeans for {{org.apache.logging.log4j2}}
are still displayed. Accessing their attributes may cause errors in the
Tomcat console (INFO: Illegal access: this web application instance has been
stopped already. Could not load
sun.reflect.SerializationConstructorAccessorImpl. The eventual following
stack trace is caused by an error thrown for debugging purposes as well as to
attempt to terminate the thread which caused the illegal access, and has no
functional impact. java.lang.IllegalStateException...)
#* *Bad sign #3:* In the Tomcat manager app, pressing the Find Leaks button
shows this message: The following web applications were stopped (reloaded,
undeployed), but their classes from previous runs are still loaded in memory,
thus causing a memory leak (use a profiler to confirm): /webapp1
So with the default setup, undeploying a webapp with log4j2 in its
WEB-INF/lib folder does not automatically call {{LoggerContext.stop()}}.
Things do seem to work better if I modify the {{web.xml}} file and add the
listener, filter and filter-mapping [recommended for Servlet 2.5 web
[jira] [Commented] (LOG4J2-500) Unloading one webapp unloads JMX MBeans for all webapps
[
https://issues.apache.org/jira/browse/LOG4J2-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13888026#comment-13888026
]
Nick Williams commented on LOG4J2-500:
--
It can be both.
If a web application has the Log4j libraries in its {{/WEB-INF/lib}} directory,
it ALWAYS has its own {{StatusLogger}} class that is not the same as the
{{StatusLogger}} class of any application or the container. This is true even
if the container also provides Log4j libraries. However, if the container
provides Log4j libraries and the application DOES NOT, then an application
would share the container's {{StatusLogger}} class.
So with all that said, the most complex scenario imaginable is that the
container provides the Log4j libraries, multiple applications are deployed, and
some of those applications provide their own Log4j libraries while others
don't. In this case, there will be multiple {{StatusLogger}} classes, but not
necessarily as many as there are applications using Log4j. Fun, huh?
So, in short, the GUI _does_ need to show separate text areas for each
StatusLogger.
Unloading one webapp unloads JMX MBeans for all webapps
---
Key: LOG4J2-500
URL: https://issues.apache.org/jira/browse/LOG4J2-500
Project: Log4j 2
Issue Type: Bug
Components: JMX
Affects Versions: 2.0-rc1
Reporter: Remko Popma
Assignee: Remko Popma
As a stopgap solution for LOG4J2-406, all MBeans are unregistered when a
LoggerContext is stopped.
In an application server, multiple web applications can be deployed and
undeployed independently and a better solution would only unregister the
MBeans associated with the web application that is being undeployed.
Current MBean ObjectNames look like this (simplified):
{code}
...StatusLogger
...ContextSelector
...LoggerContext,ctx=%s
...LoggerConfig,ctx=%s,name=%s
...Appender,ctx=%s,name=%s
...
{code}
Assuming that every web application has a unique name, and this name becomes
the name of the LoggerContext, then one solution would be to create
StatusLogger and ContextSelector MBeans that have the LoggerContext name in
their ObjectName:
{code}
...StatusLogger,ctx=%s
...ContextSelector,ctx=%s
...LoggerContext,ctx=%s
...LoggerConfig,ctx=%s,name=%s
...Appender,ctx=%s,name=%s
...
{code}
This way, every web application would have its own StatusLogger and
ContextSelector MBeans. The MBeans may point to the same (shared) underlying
StatusLogger and ContextSelector objects. When a web application is
undeployed, unregistering all MBeans associated with the LoggerContext will
not affect any MBeans associated with another web application (which has it
own, separate, LoggerContext).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Reopened] (LOG4J2-323) ThreadLocal-leak on tomcat shutdown when using async logging
[
https://issues.apache.org/jira/browse/LOG4J2-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reopened LOG4J2-323:
--
Remko,
Nulling out the reference to the {{ThreadLocal}} is not enough (in fact, it's
not even necessary). If it were enough, then once the object holding the
reference was eligible for garbage collection the {{ThreadLocal}} would go
away—but it doesn't.
To remove a {{ThreadLocal}}'s contents, you must call the {{remove}} method on
the {{ThreadLocal}}. There is no reason to null out the {{ThreadLocal}}
instance once {{remove}} has been called.
I'll have this fixed shortly.
ThreadLocal-leak on tomcat shutdown when using async logging
Key: LOG4J2-323
URL: https://issues.apache.org/jira/browse/LOG4J2-323
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta9
Environment: Mac OS X 10.8.4, Tomcat 7.0.42, java version 1.6.0_51
Reporter: Michael Kloster
Assignee: Remko Popma
Priority: Minor
Fix For: 2.0-rc1
When shutting down Tomcat 7.0.42, catalina.out displays the following warning
indicating a memory leak:
{code}
Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
Jul 28, 2013 9:55:59 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 841 ms
Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardServer await
INFO: A valid shutdown command was received via the shutdown port. Stopping
the Server instance.
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [ajp-bio-8009]
Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service Catalina
Jul 28, 2013 9:56:09 AM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks
SEVERE: The web application [/asynclog] created a ThreadLocal with key of
type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@648bfdea]) and a
value of type [org.apache.logging.log4j.core.async.AsyncLogger.Info] (value
[org.apache.logging.log4j.core.async.AsyncLogger$Info@4e26d560]) but failed
to remove it when the web application was stopped. Threads are going to be
renewed over time to try and avoid a probable memory leak.
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler [ajp-bio-8009]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler [ajp-bio-8009]
{code}
{code:xml|title=log4j2.xml|borderStyle=solid}
?xml version=1.0 encoding=UTF-8?
configuration status=WARN
appenders
FastRollingFile name=MyFileLog filename=logs/my.log
filePattern=logs/my-%d{COMPACT}.log
PatternLayout pattern=%d %p %c{1.} [%t] %m%n /
Policies
SizeBasedTriggeringPolicy size=5MB /
/Policies
/FastRollingFile
Console name=Console target=SYSTEM_OUT
PatternLayout pattern=%d %p %c{1.} [%t] %m%n /
/Console
/appenders
loggers
logger name=mylogger level=INFO additivity=false
appender-ref ref=MyFileLog /
/logger
root level=TRACE
appender-ref ref=Console /
/root
/loggers
/configuration
{code}
{code:title=log4j2.xml|borderStyle=solid}
#!/bin/bash
CATALINA_OPTS=-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-323) ThreadLocal-leak on tomcat shutdown when using async logging
[
https://issues.apache.org/jira/browse/LOG4J2-323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-323.
--
Resolution: Fixed
Fixed with r1562688. Please verify and close.
ThreadLocal-leak on tomcat shutdown when using async logging
Key: LOG4J2-323
URL: https://issues.apache.org/jira/browse/LOG4J2-323
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta9
Environment: Mac OS X 10.8.4, Tomcat 7.0.42, java version 1.6.0_51
Reporter: Michael Kloster
Assignee: Nick Williams
Priority: Minor
Fix For: 2.0-rc1
When shutting down Tomcat 7.0.42, catalina.out displays the following warning
indicating a memory leak:
{code}
Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:55:59 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler [ajp-bio-8009]
Jul 28, 2013 9:55:59 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 841 ms
Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardServer await
INFO: A valid shutdown command was received via the shutdown port. Stopping
the Server instance.
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol pause
INFO: Pausing ProtocolHandler [ajp-bio-8009]
Jul 28, 2013 9:56:09 AM org.apache.catalina.core.StandardService stopInternal
INFO: Stopping service Catalina
Jul 28, 2013 9:56:09 AM org.apache.catalina.loader.WebappClassLoader
checkThreadLocalMapForLeaks
SEVERE: The web application [/asynclog] created a ThreadLocal with key of
type [java.lang.ThreadLocal] (value [java.lang.ThreadLocal@648bfdea]) and a
value of type [org.apache.logging.log4j.core.async.AsyncLogger.Info] (value
[org.apache.logging.log4j.core.async.AsyncLogger$Info@4e26d560]) but failed
to remove it when the web application was stopped. Threads are going to be
renewed over time to try and avoid a probable memory leak.
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol stop
INFO: Stopping ProtocolHandler [ajp-bio-8009]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler [http-bio-8080]
Jul 28, 2013 9:56:09 AM org.apache.coyote.AbstractProtocol destroy
INFO: Destroying ProtocolHandler [ajp-bio-8009]
{code}
{code:xml|title=log4j2.xml|borderStyle=solid}
?xml version=1.0 encoding=UTF-8?
configuration status=WARN
appenders
FastRollingFile name=MyFileLog filename=logs/my.log
filePattern=logs/my-%d{COMPACT}.log
PatternLayout pattern=%d %p %c{1.} [%t] %m%n /
Policies
SizeBasedTriggeringPolicy size=5MB /
/Policies
/FastRollingFile
Console name=Console target=SYSTEM_OUT
PatternLayout pattern=%d %p %c{1.} [%t] %m%n /
/Console
/appenders
loggers
logger name=mylogger level=INFO additivity=false
appender-ref ref=MyFileLog /
/logger
root level=TRACE
appender-ref ref=Console /
/root
/loggers
/configuration
{code}
{code:title=log4j2.xml|borderStyle=solid}
#!/bin/bash
CATALINA_OPTS=-DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-522) Split Logger interface in two with named level methods (info, warn, ...) in the subinterface.
[ https://issues.apache.org/jira/browse/LOG4J2-522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13886359#comment-13886359 ] Nick Williams commented on LOG4J2-522: -- -0: Paul has suggested we hold off on Using Custom Levels with a Custom/Wrapper Interface until a request actually comes in for it from the community. I +1ed his suggestion. If we indeed decide to hold off on that, there is _no_ reason to do this task yet. In fact, there's compelling reason _not_ to do this task yet: * If we decide to proceed with Using Custom Levels with a Custom/Wrapper Interface at a later point—whether it's 2.0.x or 2.1, etc.—we _*CAN*_ split these interfaces without affecting binary compatibility. * However, if we split these interfaces now, we _*CANNOT*_ un-split them without affecting binary compatibility. Split Logger interface in two with named level methods (info, warn, ...) in the subinterface. - Key: LOG4J2-522 URL: https://issues.apache.org/jira/browse/LOG4J2-522 Project: Log4j 2 Issue Type: Improvement Components: API Affects Versions: 2.0-beta9 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) Maven home: C:\Java\apache-maven-3.1.1\bin\.. Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary Gregory Attachments: log4j-522.diff Split Logger interface in two with named level methods (info, warn, ...) in the subinterface. This should help create custom loggers that are not tied to the stock Level DSL. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-512) Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while automatically starting, and configurable to initialize and de-initialize loggers
[ https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885050#comment-13885050 ] Nick Williams commented on LOG4J2-512: -- Documentation updated with r1562365. Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while automatically starting, and configurable to initialize and de-initialize loggers Key: LOG4J2-512 URL: https://issues.apache.org/jira/browse/LOG4J2-512 Project: Log4j 2 Issue Type: Sub-task Components: Configurators, Core, Documentation, Filters Affects Versions: 2.0-beta8, 2.0-beta9 Reporter: Chandra Sekhar Kakarla Assignee: Nick Williams Labels: asynchronous, configuration, destroy, filters, initialization, listener, log4j2, log4j2.xml, restart, servlet, servlet-context Fix For: 2.0-rc1 Original Estimate: 466h Remaining Estimate: 466h Async servlet (async-supported=true) using with log4j2 breaks the async chain because it does not support async. All element in the chain must support async in order to use async. Implementation is required to support async servlets(async-supportd=true) it may be automatic or configurable initialization. ( this Issue may be dependent on the issue https://issues.apache.org/jira/browse/LOG4J2-270 ) Initialization and de-initialization of the logger must be configurable in the java code/config files, to re-load the logger with different properties, that will help the application to reduce re-start burden when it need to use different properties. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-508) Add new Levels: NOTICE, DIAG, VERBOSE.
[ https://issues.apache.org/jira/browse/LOG4J2-508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885054#comment-13885054 ] Nick Williams commented on LOG4J2-508: -- Can we close this as won't fix now, or are we still debating it? Add new Levels: NOTICE, DIAG, VERBOSE. -- Key: LOG4J2-508 URL: https://issues.apache.org/jira/browse/LOG4J2-508 Project: Log4j 2 Issue Type: Improvement Components: API Affects Versions: 2.0-beta9 Environment: Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:22-0400) Maven home: C:\Java\apache-maven-3.1.1\bin\.. Java version: 1.7.0_51, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.7.0_51\jre Default locale: en_US, platform encoding: Cp1252 OS name: windows 7, version: 6.1, arch: amd64, family: windows Reporter: Gary Gregory Fix For: 2.0-rc1 Discussion thread: https://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201401.mbox/ajax/%3CBD972E2F-C818-47BD-BB9E-168D52D5D980%40nicholaswilliams.net%3E The levels: - FATAL - Hopefully, almost never logged because the system is crashing. - ERROR - Something affecting the usability of the system occurred. - WARN - Something not nice, but probably recoverable occurred. May lead to errors later. - NOTICE - An event for normal, but significant, conditions. - INFO - Something of general interest, but not necessarily significant. - DIAG or DIAGNOSTIC - Events that can be used by operations or users to diagnose problems in the system. - DEBUG - Used by developers for internal debugging. - VERBOSE - Used to log minute details of the system. As its dictionary definition implies this is extremely chatty. - TRACE - Adds tracing of method entry and exit, possibly object creation and initialization. From (with the NOTICE level added) https://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201401.mbox/browser -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-492) MalformedObjectNameException: Invalid escape sequence... under Jetty
[
https://issues.apache.org/jira/browse/LOG4J2-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885056#comment-13885056
]
Nick Williams commented on LOG4J2-492:
--
Remko, what's the status on this? I see that it has gone back and forth a few
times.
MalformedObjectNameException: Invalid escape sequence... under Jetty
Key: LOG4J2-492
URL: https://issues.apache.org/jira/browse/LOG4J2-492
Project: Log4j 2
Issue Type: Bug
Components: JMX
Affects Versions: 2.0-rc1
Environment: jetty.version=8.1.14.v20131031
Reporter: Shaddy Baddah
Assignee: Remko Popma
Priority: Minor
Fix For: 2.0-rc1, 2.0
Attachments: Server.java
Although it is not stopping my webapp from running, I am encountering the
following exception when running jetty (via Maven) for a webapp using a trunk
build of log4j2.
My debug line is also included:
{noformat}
loggerContext.getName()= WebAppClassLoader=1320771902@4eb9613e
2014-01-09 13:28:52,904 ERROR Could not register mbeans
java.lang.IllegalStateException:
javax.management.MalformedObjectNameException: Invalid escape sequence '\='
in quoted value
at
org.apache.logging.log4j.core.jmx.LoggerContextAdmin.init(LoggerContextAdmin.java:81)
at
org.apache.logging.log4j.core.jmx.Server.registerContexts(Server.java:266)
at
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:185)
at
org.apache.logging.log4j.core.jmx.Server.reregisterMBeansAfterReconfigure(Server.java:150)
at
org.apache.logging.log4j.core.LoggerContext.reconfigure(LoggerContext.java:387)
at
org.apache.logging.log4j.core.LoggerContext.start(LoggerContext.java:151)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:105)
at
org.apache.logging.log4j.core.impl.Log4jContextFactory.getContext(Log4jContextFactory.java:33)
at org.apache.logging.log4j.LogManager.getContext(LogManager.java:222)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:103)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:63)
at
org.apache.logging.log4j.core.web.Log4jWebInitializerImpl.initializeNonJndi(Log4jWebInitializerImpl.java:136)
at
org.apache.logging.log4j.core.web.Log4jWebInitializerImpl.initialize(Log4jWebInitializerImpl.java:82)
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:41)
at
org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(ContainerInitializer.java:106)
at
org.eclipse.jetty.annotations.ServletContainerInitializerListener.doStart(ServletContainerInitializerListener.java:107)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
at
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
at
org.eclipse.jetty.server.handler.ScopedHandler.doStart(ScopedHandler.java:115)
at
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:763)
at
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:249)
at
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
at
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at
org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:298)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:172)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at
org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
[jira] [Commented] (LOG4J2-444) Log4j2 eclipselink integration
[ https://issues.apache.org/jira/browse/LOG4J2-444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885059#comment-13885059 ] Nick Williams commented on LOG4J2-444: -- Hemri, it occurred to me that you could mean one of two things. Do you: A) Want to write your logs to a database using EclipseLink as a JPA implementation? Or, B) Want EclipseLink's internal logging statements to go through your Log4j configuration? Log4j2 eclipselink integration -- Key: LOG4J2-444 URL: https://issues.apache.org/jira/browse/LOG4J2-444 Project: Log4j 2 Issue Type: Question Affects Versions: 2.0-beta9 Reporter: Hemri Hi everyone, I wanted to know If someone knows a way to integrate eclipselink logger with log4j2. I try to do it myself but I didn't succeed. Thanks ! -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-245) EmptyStackException when logging exceptions with Log4J2 in Java 8
[ https://issues.apache.org/jira/browse/LOG4J2-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13885070#comment-13885070 ] Nick Williams commented on LOG4J2-245: -- Max, I cannot replicate this in Java 1.7.0_45 or Java 8 on my Mac. Are you sure that you have deleted ALL beta4 JARs and replaced them with beta9 JARs? EmptyStackException when logging exceptions with Log4J2 in Java 8 - Key: LOG4J2-245 URL: https://issues.apache.org/jira/browse/LOG4J2-245 Project: Log4j 2 Issue Type: Bug Components: Core, JCL Bridge Affects Versions: 2.0-beta5, 2.0-beta6 Environment: Java 8 (1.8.0-ea-b88) Reporter: Nick Williams Priority: Blocker Fix For: 2.0-beta7 [Note: the description below is the original error report. After analysis it turned out that this problem will happen unconditionally when logging a Throwable on a Java 8 JVM.] Possibly affects earlier versions, too, but I did not check. beta5 and beta6 are both unusable with Spring Framework. Any time an error gets logged through log4j-jcl bridge using Spring, the error below appears in the Tomcat log, masking the error that Spring was trying to log and making it very difficult to figure out what happened. I've also included my configuration file below the stack trace. The root error is happening on Tomcat 6 due to Spring bug, and that root problem is unimportant. The important problem is the Log4j error that masks it. SEVERE: Exception sending context initialized event to listener instance of class org.springframework.web.context.ContextLoaderListener java.util.EmptyStackException at java.util.Stack.peek(Stack.java:102) at org.apache.logging.log4j.core.impl.ThrowableProxy.resolvePackageData(ThrowableProxy.java:339) at org.apache.logging.log4j.core.impl.ThrowableProxy.init(ThrowableProxy.java:71) at org.apache.logging.log4j.core.impl.Log4jLogEvent.init(Log4jLogEvent.java:110) at org.apache.logging.log4j.core.impl.Log4jLogEvent.init(Log4jLogEvent.java:81) at org.apache.logging.log4j.core.config.LoggerConfig.createEvent(LoggerConfig.java:423) at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:344) at org.apache.logging.log4j.core.Logger.log(Logger.java:110) at org.apache.logging.log4j.spi.AbstractLoggerWrapper.log(AbstractLoggerWrapper.java:55) at org.apache.logging.log4j.spi.AbstractLogger.error(AbstractLogger.java:539) at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:319) at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4765) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5210) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:702) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:698) at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1491) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:468) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:415) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:491) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:300) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:792) at
[jira] [Updated] (LOG4J2-242) Make Messages more fluent
[
https://issues.apache.org/jira/browse/LOG4J2-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-242:
-
Attachment: LOG4J2-242.patch
I meant to attach this patch ages ago and never did it. These are my shelved
changes where I got about 3/4 of the way there implementing this (3/8 if you
include tests I hadn't yet written).
Make Messages more fluent
-
Key: LOG4J2-242
URL: https://issues.apache.org/jira/browse/LOG4J2-242
Project: Log4j 2
Issue Type: Improvement
Components: API
Affects Versions: 2.0-beta5
Reporter: Bruce Brouwer
Assignee: Nick Williams
Labels: backlog
Attachments: LOG4J2-242.patch
Original Estimate: 48h
Remaining Estimate: 48h
I really like the feature were we can pass in a Message object into the
logger methods. However, it bugs me that some of the implementations of
Message provide vararg constructors, and others only provide an Object[]
parameter. I really would like to write this code:
log.info(new ParameterizedMessage(abc: {} xyz: {}, abc, xyz),
throwable);
I realize that this particular example would work with this code by default:
log.info(abc: {} xyz: {}, abc, xyz, throwable);
But the other Message implementations don't provide a vararg constructor, nor
do they try to detect the last parameter as a Throwable.
[LOG4J2-48] addresses some of the complexity of having varargs with the last
vararg being an implicit final parameter, but again, this only works with
ParameterizedMessage. But I would like this to be more consistent across the
board. One idea that I had was this:
log.info(new ParameterizedMessage(abc: {} xyz: {}, abc,
xyz).throwing(throwable));
Now all of the message constructors (not just ParameterizedMessage) could
have varargs with none of them providing a Throwable parameter in the
constructor, but provided through a more fluent API. I don't know that it
would warrant adding it to the Message interface, but we could go further
with it by adding these methods:
Message withParameters(Object... parameters);
Message throwing(Throwable throwable);
It wouldn't be absolutely necessary as the concrete implementations could
define that and work in my case.
Another idea that I had was maybe a bit more impactful to the Logger API.
What if I wrote my code like this:
log.with(exception).info(abc: {} xyz: {}, abc, xyz);
// or maybe this
log.message(abc: {} xyz: {}, abc, xyz).with(exception).info();
That would necessitate something like a LogBuilder interface, maybe tie it
into the MessageFactory classes. This LogBuilder interface could have these
methods:
LogBuilder message(String pattern, Object... params);
LogBuilder with(Throwable t);
LogBuilder marker(Marker marker);
LogBuilder level(Level level);
void info(); // and others like it
void info(String pattern, Object... params); // and others like it
I'm not exactly sure what the best way would be to go and implement this as
I'm sure you don't want to have objects created all over the place.
Is this an idea worth pursuing a bit further?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-359.
--
Resolution: Fixed
This is fixed with r1561933. Unfortunately, WebLogic is simply not spec
compliant here. There's no standard way other than {{getEffectiveMajorVersion}}
to detect the Servlet version. However, a new setting being added (which will
be documented) as part of a separate bug allows you to disable
auto-initialization, which you can do as a work around in WebLogic with you set
the Servlet version to 2.5. Meanwhile, I suggest you report this bug with
{{getEffectiveMajorVersion}} to Oracle/WebLogic. I have seen others complaining
about it online, but no responses from Oracle.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Fix For: 2.0-rc1
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated.
[jira] [Resolved] (LOG4J2-344) Log4j2 doesnt work with Weblogic 12c
[ https://issues.apache.org/jira/browse/LOG4J2-344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams resolved LOG4J2-344. -- Resolution: Fixed Fix Version/s: 2.0-rc1 Sorry for the delay. This has been fixed with r1561937. Log4j2 doesnt work with Weblogic 12c Key: LOG4J2-344 URL: https://issues.apache.org/jira/browse/LOG4J2-344 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.0-beta8 Environment: Windows XP SP 3 Reporter: Keir Assignee: Nick Williams Fix For: 2.0-rc1 Attachments: web.xml I get a Context destroyed before it was initialized exception, the problem seems to be that the servlet filters init method is not being called by WebLogic, not sure why... -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-409) Specifying log4jConfiguration in web.xml fails on Windows when using ${user.home}
[
https://issues.apache.org/jira/browse/LOG4J2-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-409.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Thanks for the help identifying the problem and for the patch. Had to change
URI creation in several places. Fixed with r1561945.
Specifying log4jConfiguration in web.xml fails on Windows when using
${user.home}
-
Key: LOG4J2-409
URL: https://issues.apache.org/jira/browse/LOG4J2-409
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: Windows 7, Apache Tomcat 7, Java 7
Reporter: Frank Steinmann
Assignee: Nick Williams
Fix For: 2.0-rc1
Attachments: LOG4J2-409.patch
When specifying the context parameter log4jConfiguration in the web.xml of a
web application and using $\{user.home\} as part of the path, e.g.
{code:xml}
context-param
param-namelog4jConfiguration/param-name
param-valuefile://${user.home}/someDirectory/log4j2.xml/param-value
/context-param
{code}
the following exception is thrown on Windows systems:
{noformat}
java.net.URISyntaxException: Illegal character in authority at index 7:
file://C:\Users\steinman/someDirectory/log4j2.xml
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.parseAuthority(Unknown Source)
at java.net.URI$Parser.parseHierarchical(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.init(Unknown Source)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:46)
...
{noformat}
It is because of the backslashes that are not allowed in URIs.
There is an example in the documentation using backslashes
([http://logging.apache.org/log4j/2.x/manual/webapp.html]) which will produce
the same exception.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-410) java.io.NotSerializableException: org.slf4j.impl.SLF4JLogger
[ https://issues.apache.org/jira/browse/LOG4J2-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883792#comment-13883792 ] Nick Williams commented on LOG4J2-410: -- Should we take some action on this before RC1? java.io.NotSerializableException: org.slf4j.impl.SLF4JLogger - Key: LOG4J2-410 URL: https://issues.apache.org/jira/browse/LOG4J2-410 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.0-beta8 Reporter: lvlin zeng When i use a the logger object in a model,and the model will set to some cache like memcached,this exception happens.Maybe this class and some other related class need implements Serializable interface? -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-512) Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while automatically starting, and configurable to initialize and de-initialize loggers
[ https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams reassigned LOG4J2-512: Assignee: Nick Williams Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while automatically starting, and configurable to initialize and de-initialize loggers Key: LOG4J2-512 URL: https://issues.apache.org/jira/browse/LOG4J2-512 Project: Log4j 2 Issue Type: Sub-task Components: Configurators, Core, Documentation, Filters Affects Versions: 2.0-beta8, 2.0-beta9 Reporter: Chandra Sekhar Kakarla Assignee: Nick Williams Labels: asynchronous, configuration, destroy, filters, initialization, listener, log4j2, log4j2.xml, restart, servlet, servlet-context Original Estimate: 466h Remaining Estimate: 466h Async servlet (async-supported=true) using with log4j2 breaks the async chain because it does not support async. All element in the chain must support async in order to use async. Implementation is required to support async servlets(async-supportd=true) it may be automatic or configurable initialization. ( this Issue may be dependent on the issue https://issues.apache.org/jira/browse/LOG4J2-270 ) Initialization and de-initialization of the logger must be configurable in the java code/config files, to re-load the logger with different properties, that will help the application to reduce re-start burden when it need to use different properties. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-452) Log4j2 should not automatically start in Servlet 3.0
[
https://issues.apache.org/jira/browse/LOG4J2-452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883845#comment-13883845
]
Nick Williams commented on LOG4J2-452:
--
Partially fixed with r1561956 in that the filter now supports async requests
and the web support is exposed via a {{ServletContext}} attribute so that
asynchronous threads can set and clear the {{LoggerContext}}. I still need to
implement the context parameter that allows disabling auto-initialization.
Log4j2 should not automatically start in Servlet 3.0
Key: LOG4J2-452
URL: https://issues.apache.org/jira/browse/LOG4J2-452
Project: Log4j 2
Issue Type: Bug
Components: Filters
Affects Versions: 2.0-beta9
Reporter: Anthony Communier
Assignee: Nick Williams
Priority: Critical
Attachments:
0001-Add-LOGGER_CONTEXT_ATTRIBUTE-to-LoggerContext.patch,
0002-Add-async-support-to-Log4jServletFilter.patch, log4-servlet-test.zip,
patch_async.diff
When using async servlet (async-supported=true inweb.xml), log4j2 breaks the
async chain because it does not support async. All element in the chain must
support async in order to use async. Using Log4j2 in web context lead to be
unable to use async.
Be aware that async mecanism is more complicated than just intercept the
chain before and after the handling of the request (thing that could be done
in sync context). When using async mecanism web container threads can be used
when the start method is invoked on AsyncContext and there are no way to
intercept this systematically.
So I m not sure that it's a good idea to automatically intercept request
with a filter.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-512) Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while automatically starting, and configurable to initialize and de-initialize loggers
[
https://issues.apache.org/jira/browse/LOG4J2-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-512.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
Fixed with r1561956. This exposes the web support _and_ the {{LoggerContext}}
as {{ServletContext}} attributes, allowing code in asynchronous threads to set
and clear the context as necessary and convenient. It also makes the filter
support asynchronous requests. Tomorrow I will commit a separate revision with
some web-related documentation updates.
Log4j2 need to support Asynchronous Servlets/ Servlet 3.0 while automatically
starting, and configurable to initialize and de-initialize loggers
Key: LOG4J2-512
URL: https://issues.apache.org/jira/browse/LOG4J2-512
Project: Log4j 2
Issue Type: Sub-task
Components: Configurators, Core, Documentation, Filters
Affects Versions: 2.0-beta8, 2.0-beta9
Reporter: Chandra Sekhar Kakarla
Assignee: Nick Williams
Labels: asynchronous, configuration, destroy, filters,
initialization, listener, log4j2, log4j2.xml, restart, servlet,
servlet-context
Fix For: 2.0-rc1
Original Estimate: 466h
Remaining Estimate: 466h
Async servlet (async-supported=true) using with log4j2 breaks the async chain
because it does not support async.
All element in the chain must support async in order to use async.
Implementation is required to support async servlets(async-supportd=true) it
may be automatic or configurable initialization. ( this Issue may be
dependent on the issue https://issues.apache.org/jira/browse/LOG4J2-270 )
Initialization and de-initialization of the logger must be configurable in
the java code/config files, to re-load the logger with different properties,
that will help the application to reduce re-start burden when it need to use
different properties.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-500) Unloading one webapp unloads JMX MBeans for all webapps
[
https://issues.apache.org/jira/browse/LOG4J2-500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13883857#comment-13883857
]
Nick Williams commented on LOG4J2-500:
--
Remko, have you had a chance to look at this anymore? We should get this fixed
before GA.
Unloading one webapp unloads JMX MBeans for all webapps
---
Key: LOG4J2-500
URL: https://issues.apache.org/jira/browse/LOG4J2-500
Project: Log4j 2
Issue Type: Bug
Components: JMX
Affects Versions: 2.0-rc1
Reporter: Remko Popma
As a stopgap solution for LOG4J2-406, all MBeans are unregistered when a
LoggerContext is stopped.
In an application server, multiple web applications can be deployed and
undeployed independently and a better solution would only unregister the
MBeans associated with the web application that is being undeployed.
Current MBean ObjectNames look like this (simplified):
{code}
...StatusLogger
...ContextSelector
...LoggerContext,ctx=%s
...LoggerConfig,ctx=%s,name=%s
...Appender,ctx=%s,name=%s
...
{code}
Assuming that every web application has a unique name, and this name becomes
the name of the LoggerContext, then one solution would be to create
StatusLogger and ContextSelector MBeans that have the LoggerContext name in
their ObjectName:
{code}
...StatusLogger,ctx=%s
...ContextSelector,ctx=%s
...LoggerContext,ctx=%s
...LoggerConfig,ctx=%s,name=%s
...Appender,ctx=%s,name=%s
...
{code}
This way, every web application would have its own StatusLogger and
ContextSelector MBeans. The MBeans may point to the same (shared) underlying
StatusLogger and ContextSelector objects. When a web application is
undeployed, unregistering all MBeans associated with the LoggerContext will
not affect any MBeans associated with another web application (which has it
own, separate, LoggerContext).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Resolved] (LOG4J2-452) Log4j2 should not automatically start in Servlet 3.0
[
https://issues.apache.org/jira/browse/LOG4J2-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-452.
--
Resolution: Fixed
Fix Version/s: 2.0-rc1
The rest of this has been fixed with r1561958, which adds a {{ServletContext}}
parameter for disabling auto-initialization. A separate commit tomorrow will
provide several updates to Log4j's web app documentation.
Log4j2 should not automatically start in Servlet 3.0
Key: LOG4J2-452
URL: https://issues.apache.org/jira/browse/LOG4J2-452
Project: Log4j 2
Issue Type: Bug
Components: Filters
Affects Versions: 2.0-beta9
Reporter: Anthony Communier
Assignee: Nick Williams
Priority: Critical
Fix For: 2.0-rc1
Attachments:
0001-Add-LOGGER_CONTEXT_ATTRIBUTE-to-LoggerContext.patch,
0002-Add-async-support-to-Log4jServletFilter.patch, log4-servlet-test.zip,
patch_async.diff
When using async servlet (async-supported=true inweb.xml), log4j2 breaks the
async chain because it does not support async. All element in the chain must
support async in order to use async. Using Log4j2 in web context lead to be
unable to use async.
Be aware that async mecanism is more complicated than just intercept the
chain before and after the handling of the request (thing that could be done
in sync context). When using async mecanism web container threads can be used
when the start method is invoked on AsyncContext and there are no way to
intercept this systematically.
So I m not sure that it's a good idea to automatically intercept request
with a filter.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-479) Use of InheritableThreadLocal in Map ThreadContext is dangerous and unhelpful
[
https://issues.apache.org/jira/browse/LOG4J2-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861703#comment-13861703
]
Nick Williams commented on LOG4J2-479:
--
In my opinion, we need to take one of two paths:
#Remove uses of {{InheritableThreadLocal}} completely.
#Make a system option to enable use of {{InheritableThreadLocal}}, but *disable
it by default* so that values are not inherited unless specifically enabled.
In applications that use thread pools to spin off long-running processes (and
this is a lot of applications), an {{InheritableThreadLocal}} is *dangerous*.
Before the thread pool is used for the first time, it is initially empty. It
hasn't yet created any threads. If a thread sets the value in an
{{InheritableThreadLocal}} and then borrows a thread from that pool, the pool
will create a thread with the same {{InheritableThreadLocal}} values. That
thread will then always have that value, even after the application returns it
to the pool. Even worse, in a web application multiple applications could share
a single thread pool, resulting in information leaking from one application to
another.
Use of InheritableThreadLocal in Map ThreadContext is dangerous and unhelpful
-
Key: LOG4J2-479
URL: https://issues.apache.org/jira/browse/LOG4J2-479
Project: Log4j 2
Issue Type: Bug
Reporter: MK
Described here http://logging.apache.org/log4j/2.x/manual/thread-context.html
The use of InheritableThreadLocal creates subtle and hard to track bugs while
not really adding much useful. It is counterintuitive -- I don't see why
would anyone expect logging context to be inherited. But it breaks down
completely when used with Thread Executors.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Comment Edited] (LOG4J2-479) Use of InheritableThreadLocal in Map ThreadContext is dangerous and unhelpful
[
https://issues.apache.org/jira/browse/LOG4J2-479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13861703#comment-13861703
]
Nick Williams edited comment on LOG4J2-479 at 1/3/14 5:40 PM:
--
In my opinion, we need to take one of two paths:
# Remove uses of {{InheritableThreadLocal}} completely.
# Make a system option to enable use of {{InheritableThreadLocal}}, but
*disable it by default* so that values are not inherited unless specifically
enabled.
In applications that use thread pools to spin off long-running processes (and
this is a lot of applications), an {{InheritableThreadLocal}} is *dangerous*.
Before the thread pool is used for the first time, it is initially empty. It
hasn't yet created any threads. If a thread sets the value in an
{{InheritableThreadLocal}} and then borrows a thread from that pool, the pool
will create a thread with the same {{InheritableThreadLocal}} values. That
thread will then always have that value, even after the application returns it
to the pool. Even worse, in a web application multiple applications could share
a single thread pool, resulting in information leaking from one application to
another.
was (Author: beamerblvd):
In my opinion, we need to take one of two paths:
#Remove uses of {{InheritableThreadLocal}} completely.
#Make a system option to enable use of {{InheritableThreadLocal}}, but *disable
it by default* so that values are not inherited unless specifically enabled.
In applications that use thread pools to spin off long-running processes (and
this is a lot of applications), an {{InheritableThreadLocal}} is *dangerous*.
Before the thread pool is used for the first time, it is initially empty. It
hasn't yet created any threads. If a thread sets the value in an
{{InheritableThreadLocal}} and then borrows a thread from that pool, the pool
will create a thread with the same {{InheritableThreadLocal}} values. That
thread will then always have that value, even after the application returns it
to the pool. Even worse, in a web application multiple applications could share
a single thread pool, resulting in information leaking from one application to
another.
Use of InheritableThreadLocal in Map ThreadContext is dangerous and unhelpful
-
Key: LOG4J2-479
URL: https://issues.apache.org/jira/browse/LOG4J2-479
Project: Log4j 2
Issue Type: Bug
Reporter: MK
Described here http://logging.apache.org/log4j/2.x/manual/thread-context.html
The use of InheritableThreadLocal creates subtle and hard to track bugs while
not really adding much useful. It is counterintuitive -- I don't see why
would anyone expect logging context to be inherited. But it breaks down
completely when used with Thread Executors.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-41) Extensible Log Level
[
https://issues.apache.org/jira/browse/LOG4J2-41?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13831753#comment-13831753
]
Nick Williams commented on LOG4J2-41:
-
So I hate to reopen old wounds, but I'm going to give a little bit of a gripe
here. I'm in the review stage for my book, and I just read the following
sentences in my logging chapter:
{quote}Because {{Level}} is an enum, it cannot be extended. These are the only
levels you can use in Log4j 2.{quote}
This made me cringe, and reminded me of this issue. This keeps coming up in the
mailing list, and for good reason. The logging levels we have defined work well
for most developers. But the {{Level}} enum is *not* an _exhaustive_ list of
every level every developer will ever need. Yes, that's a *good* thing—an enum
with dozens of levels in it (and a {{Logger}} API to match) would be useless.
However, the use of an enum makes it _very hard_ for developers to adapt Log4j
to suit their needs. I'm going to use a hypothetical {{CONFIG}} level, which
logically falls somewhere between {{WARN}} and {{INFO}} for my purposes. I
would use this level to log when configuration settings changed or to log the
current value of configuration settings on application startup.
Currently, the {{Logger}} API provides no mechanism for me to use anything
outside the {{Level}} levels. I must choose one of those for logging my
{{CONFIG}} events. So then how do I use {{CONFIG}}? Well, I have to define a
{{Marker}}. Then I have to use both a {{Level}} (probably {{INFO}}) and a
{{Marker}} on my {{CONFIG}} events. Then I have to properly configure a
{{Filter}}, and get it in the correct place, to intercept those logging events
and inspect the {{Marker}}. All of this is much more difficult than simply
using this line of code:
{code:java}logger.log(MyLevels.CONFIG, The current config setting is
{}., setting);{code}
Now, what could {{MyLevels.CONFIG}} be? Two comments above this one, Paul
suggests that it should be an {{int}}, and that we should add methods to the
{{Logger}} API to accept an {{int}} that can be compared to the other {{Level}}
constants and logged appropriately. Why? So that {{Logger}} can have
_*SIXTEEN*_ more methods than it already does? Why not just re-use the methods
that accept a {{Level}}? And that's not even including the {{throwing}} and
{{catching}} methods, so actually eighteen new methods. How does this improve
the API but making {{Level}} extendable does not?
One way or another, I think it's a must for us to resolve a way to define your
own levels before Log4j can be released (and I so want to release it). Whether
that's making {{Level}} extendable or adding eighteen {{int}} methods to
{{Logger}} is a matter that merits discussion, but however it's done, it needs
to be done.
Four comments above, I provide a detailed example of how {{Level}} can be made
extendable _*without breaking the API*_. It's a binary-compatible change.
Existing code compiled against Log4j would continue to work with my proposed
change. I've read five or six seconds to my proposal since I posted it in
March. It seems like a safe and powerful change to make, so I'm bringing it
back up for discussion in the hopes that it will at least trigger some new
ideas, if not some agreement.
Extensible Log Level
Key: LOG4J2-41
URL: https://issues.apache.org/jira/browse/LOG4J2-41
Project: Log4j 2
Issue Type: Improvement
Components: API
Reporter: Ralph Goers
It is desirable to have the Level be an enum. However, it is also desirable
to let users add new log levels. These goals are in opposition to each other
since enum classes are final. In addition, adding new levels implies adding
new methods to the Logger interface (or some counterpart to it). This would
be unworkable.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-438) JDBCDatabaseManager does not send commit command
[
https://issues.apache.org/jira/browse/LOG4J2-438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-438:
Assignee: Nick Williams
JDBCDatabaseManager does not send commit command
Key: LOG4J2-438
URL: https://issues.apache.org/jira/browse/LOG4J2-438
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta9
Environment: Java 7u45, Windows, H2
Reporter: Ralph Schaer
Assignee: Nick Williams
Priority: Minor
I'm fiddling with the log4j jdbc appender and found an issue with datasources
that have the flag defaultAutoCommit set to false. With such datasources the
application has to call the method connection.commit() after an update
statement, if omitted nothing will be updated or inserted in the database.
That is the problem with the class JDBCDatabaseManager. It executes the
statement (with this.statement.executeUpdate()) but does not call commit.
Nothing is inserted if the defaultAutoCommit flag of the datasource is set to
false.
One possible solution is to check the autoCommit flag of the datasource and
call commit when it's set to false.
if (this.statement.executeUpdate() == 0) {
throw new AppenderLoggingException(
No records inserted in database table for log event in JDBC manager.);
}
if (!this.connection.getAutoCommit()) {
this.connection.commit();
}
Maybe this has to be done differently when a buffer is used. The method
AbstractDatabaseManager.flush should only call commit after the loop.
if (this.isConnected() this.buffer.size() 0) {
for (final LogEvent event : this.buffer) {
this.writeInternal(event);
}
if (!connection.getAutoCommit()) {
connection.commit();
}
this.buffer.clear();
}
Or maybe using the batch methods of jdbc would improve the performance even
more
if (this.isConnected() this.buffer.size() 0) {
for (final LogEvent event : this.buffer) {
//create statement ...
statement.addBatch()
}
statement.executeBatch();
if (!connection.getAutoCommit()) {
connection.commit();
}
this.buffer.clear();
}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-424) JDBCAppender: Add support for data types other then String
[
https://issues.apache.org/jira/browse/LOG4J2-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reassigned LOG4J2-424:
Assignee: Nick Williams
JDBCAppender: Add support for data types other then String
--
Key: LOG4J2-424
URL: https://issues.apache.org/jira/browse/LOG4J2-424
Project: Log4j 2
Issue Type: Improvement
Components: Appenders
Affects Versions: 2.0-beta9
Environment: All
Reporter: Tihomir Meščić
Assignee: Nick Williams
I am using the JDBCAppender to log to a Postgresql database. I have a table
(log_entries) that's used for logging purposes.
One of the attributes is of type INTEGER. The attribute is something specific
for our application and we are using ThreadContext (MDC) to set the value of
the parameter.
Currently, log4j provides no support for integer type attributes in the
Column element of the JDBC appender configuration (the only types supported
are string (default), timestamp - isEventTimestamp flag and Clob - isClob
flag).
When using the default settings in the Column element of the JDBC appender,
log4j will create a prepared statement and try to set the value using the
Statement.setString() method. Of course, the JDBC driver throws an exception:
Caused by: org.postgresql.util.PSQLException: ERROR: column mn_type_d is of
type integer but expression is of type character varying
Hint: You will need to rewrite or cast the expression.
My appender configuration:
JDBC name=jdbcAppender tableName=log_entries
DriverManager url=jdbc:postgresql://10.28.10.32:5432/xxx
username=xxx password=xxx /
Column name=log_entries_id literal=nextval('hibernate_sequence') /
.
Column name=message isUnicode=false pattern=%message /
Column name=mn_type_d isUnicode=false pattern=%X{mn_type_d} /
-- this is of type integer in the DB but LOG4J tries to insert it as a
String --
/JDBC
--
This message was sent by Atlassian JIRA
(v6.1#6144)
-
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Assigned] (LOG4J2-422) DriverManager for JDBC Appender should have argument for explicit Driver class
[ https://issues.apache.org/jira/browse/LOG4J2-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams reassigned LOG4J2-422: Assignee: Nick Williams DriverManager for JDBC Appender should have argument for explicit Driver class -- Key: LOG4J2-422 URL: https://issues.apache.org/jira/browse/LOG4J2-422 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-beta9 Reporter: erich oliphant Assignee: Nick Williams I had a situation where the DriverManager was unable to properly load the jdbc driver (Oracle) via url resolution alone. The DriverManager doesnt' currently allow you to explicitly specify the the driver. I resolved my situation by creating my own that accepts a driver parameter, but it seems like this should be added to the core -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-422) DriverManager for JDBC Appender should have argument for explicit Driver class
[ https://issues.apache.org/jira/browse/LOG4J2-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792675#comment-13792675 ] Nick Williams commented on LOG4J2-422: -- It sounds like you are using a driver that is not compliant with Java 6. Can you please tell me your database vendor, database version number, driver vendor, and driver version number? DriverManager for JDBC Appender should have argument for explicit Driver class -- Key: LOG4J2-422 URL: https://issues.apache.org/jira/browse/LOG4J2-422 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-beta9 Reporter: erich oliphant Assignee: Nick Williams I had a situation where the DriverManager was unable to properly load the jdbc driver (Oracle) via url resolution alone. The DriverManager doesnt' currently allow you to explicitly specify the the driver. I resolved my situation by creating my own that accepts a driver parameter, but it seems like this should be added to the core -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-422) DriverManager for JDBC Appender should have argument for explicit Driver class
[ https://issues.apache.org/jira/browse/LOG4J2-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792922#comment-13792922 ] Nick Williams commented on LOG4J2-422: -- H. That's odd. Can you tell me a bit about your application/environment? Is this a web application, and if so what application server are you using? Details like that would be helpful. DriverManager for JDBC Appender should have argument for explicit Driver class -- Key: LOG4J2-422 URL: https://issues.apache.org/jira/browse/LOG4J2-422 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-beta9 Reporter: erich oliphant Assignee: Nick Williams I had a situation where the DriverManager was unable to properly load the jdbc driver (Oracle) via url resolution alone. The DriverManager doesnt' currently allow you to explicitly specify the the driver. I resolved my situation by creating my own that accepts a driver parameter, but it seems like this should be added to the core -- This message was sent by Atlassian JIRA (v6.1#6144) - To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
[jira] [Commented] (LOG4J2-409) Specifying log4jConfiguration in web.xml fails on Windows when using ${user.home}
[
https://issues.apache.org/jira/browse/LOG4J2-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774598#comment-13774598
]
Nick Williams commented on LOG4J2-409:
--
Thanks for reporting this, Frank. Looks like there are two distinct but related
problems here. First, the documentation should not show backslashes, because
those are indeed illegal in URIs. That's an easy fix. Second, the variable
substitution is resulting in an invalid URI (because of the backslashes). This
is a trickier problem, because variable solution has no idea what the semantics
of a variable value are. It could be a file path, a person's name, a database
connection, or someone's favorite color. We're either going to have to put some
context around variable substitution so that it can intelligently replace
backslashes with forward slashes, or we're going to have to deal with the
problem further down the line before converting values to URIs. I'm going to
have to think on this one for a bit.
Specifying log4jConfiguration in web.xml fails on Windows when using
${user.home}
-
Key: LOG4J2-409
URL: https://issues.apache.org/jira/browse/LOG4J2-409
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: Windows 7, Apache Tomcat 7, Java 7
Reporter: Frank Steinmann
When specifying the context parameter log4jConfiguration in the web.xml of a
web application and using $\{user.home\} as part of the path, e.g.
{code:xml}
context-param
param-namelog4jConfiguration/param-name
param-valuefile://${user.home}/someDirectory/log4j2.xml/param-value
/context-param
{code}
the following exception is thrown on Windows systems:
{noformat}
java.net.URISyntaxException: Illegal character in authority at index 7:
file://C:\Users\steinman/someDirectory/log4j2.xml
at java.net.URI$Parser.fail(Unknown Source)
at java.net.URI$Parser.parseAuthority(Unknown Source)
at java.net.URI$Parser.parseHierarchical(Unknown Source)
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.init(Unknown Source)
at
org.apache.logging.log4j.core.config.Configurator.initialize(Configurator.java:46)
...
{noformat}
It is because of the backslashes that are not allowed in URIs.
There is an example in the documentation using backslashes
([http://logging.apache.org/log4j/2.x/manual/webapp.html]) which will produce
the same exception.
--
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
[jira] [Updated] (LOG4J2-407) JDBCAppender cannot recover from loss of database connectivity
[ https://issues.apache.org/jira/browse/LOG4J2-407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams updated LOG4J2-407: - Assignee: Nick Williams JDBCAppender cannot recover from loss of database connectivity -- Key: LOG4J2-407 URL: https://issues.apache.org/jira/browse/LOG4J2-407 Project: Log4j 2 Issue Type: Bug Components: Appenders Affects Versions: 2.0-beta9 Reporter: Michael Kloster Assignee: Nick Williams The JDBCAppender holds a single database connection for all its logging. If that database connection is closed, it does not attempt to make a new connection. Many connection pools automatically close connections after a certain amount of inactivity. (This can be worked around by properly configuring a pool). Database connectivity issues are also common enough that a long running application may experience temporary network issues. When the network comes back online, the logging will not resume. I've been meaning to submit a patch for this, but I haven't gotten to it. Since I saw that you are looking to come out of beta soon, I thought I would log this issue in case someone else has time to write the patch before I get to it. -- 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
[jira] [Commented] (LOG4J2-406) JMX MBeans are not being unregistered when a tomcat web application that uses log4j is undeployed, leading to a permgen memory leak.
[
https://issues.apache.org/jira/browse/LOG4J2-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13772120#comment-13772120
]
Nick Williams commented on LOG4J2-406:
--
The {{ServletContextListener}} correctly shuts down Log4j. The problem is that
shutting down Log4j doesn't remove the MBeans. IMO, it should. Remko, can you
take a look at that?
The {{ApplicationShutdownHooks}} should be disabled in a web application
environment. I'll look at that this weekend.
JMX MBeans are not being unregistered when a tomcat web application that uses
log4j is undeployed, leading to a permgen memory leak.
Key: LOG4J2-406
URL: https://issues.apache.org/jira/browse/LOG4J2-406
Project: Log4j 2
Issue Type: Bug
Components: Core, JMX
Affects Versions: 2.0-beta9
Environment: Java 1.7.0_17-b02, tomcat 7.0.34.0, NetBeans 7.3,
Windows 7 (64 bit)
Reporter: Kerrigan Joseph
When the log4j2 library is being used with a tomcat web application (included
in the web application's libraries, not in the container's libraries), tomcat
correctly discovers and initializes the Log4jServletContainerInitializer and
adds the Log4JServletContextListener as described in the
[manual|http://logging.apache.org/log4j/2.x/manual/webapp.html] (after
removing log4j*.jar from the jarsToSkip property as described on that
page). However, two MBeans that log4j registers (ContextSelector and
StatusLogger) are never unregistered when the web application is undeployed.
This prevents the entire web application from being garbage collected and
leads to a permgen memory leak and causes an OutOfMemoryError after a few
undeploy/redeploy cycles*.
We could work around this by taking the following steps:
# Added a context parameter to the web.xml file specifying a value for the
log4jContextName parameter. This seems to prevent
java.lang.ApplicationShutdownHooks from keeping a refernce to the log4j
LoggerContext, which was part of why the memory leak was occuring**.
# In addition, took one of the following measures:
#* Added the log4j2 libraries to tomcat's classpath. Regardless of whether or
not the libraries were in the web application's classpath, this seemed to
circumvent the entire issue.
#* Disabled jmx entirely, by adding -Dlog4j.disable.jmx=true to the JVM
options for tomcat.
#* Added a custom ServletContextListener which manually unregisters all log4j
MBeans upon the destruction of the context.
Any of the steps from 2 worked equally well, but none of them worked unless
we also took step 1.
\* We used jmap and jhat to confirm that the application was not being
unloaded from memory after being undeployed, and were able to narrow the
cause down to those MBeans by tracing a reference path from the
StandardClassloader through them to the WebappClassLoader.
\** We're unsure of what role ApplicationShutdownHooks plays in this
scenario, but we observed in jhat that the reference path between log4j and
ApplicationShutdownHooks disappeared after adding the log4jContextName
parameter, and that this was necessary to stop the permgen memory leak.
--
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
[jira] [Commented] (LOG4J2-403) MongoDB appender, username and password should be optional.
[ https://issues.apache.org/jira/browse/LOG4J2-403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770506#comment-13770506 ] Nick Williams commented on LOG4J2-403: -- I'll let some of the other guys weight in before I resolve this as invalid, but I think this is the way it should be. Accessing any type of database without authentication is dangerous. Back in the day MySQL used to let you do this as the default setup, but then after several versions started forcing users to create a username and password on install. I understand what you're saying about simple development environments, but it's not really difficult to create a user with username user and password password. I prefer the added security that comes with Log4j not connecting to MongoDB unless it's an authenticated connection. In a production environment, that could save someone from a costly mistake. MongoDB appender, username and password should be optional. --- Key: LOG4J2-403 URL: https://issues.apache.org/jira/browse/LOG4J2-403 Project: Log4j 2 Issue Type: Improvement Components: Appenders Affects Versions: 2.0-beta9 Reporter: Poorna Subhash P Priority: Minor In development environments it is usual to create MongoDB without any users/restrictions. In MongoDB appender if I don't provide usrname,password or if I provide empty values, its throwing exception even without attempting for connection. Getting following error: ERROR The database is not already authenticated so you must supply a username and password for the MongoDB provider. It would be nice if there is an ability to connect to MongoDB without user details (making them optional fields). -- 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
[jira] [Comment Edited] (LOG4J2-330) NoSQLAppender cannot insert log event to MongoDB
[
https://issues.apache.org/jira/browse/LOG4J2-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770507#comment-13770507
]
Nick Williams edited comment on LOG4J2-330 at 9/18/13 6:46 AM:
---
**head desk**
That was a stupid mistake on my part. It's unfortunate that you weren't able to
verify this bug before beta9 was released. I could have gotten it fixed. But it
is what it is. The fix will be in 2.0.0.next.
was (Author: beamerblvd):
**head desk**
That was a stupid mistake on my part. It's unfortunate that you weren't able to
verify this bug before beta9 was released. I could have gotten it fixed. But it
is what it is. The fix will be in 2.0.0.GA.
NoSQLAppender cannot insert log event to MongoDB
Key: LOG4J2-330
URL: https://issues.apache.org/jira/browse/LOG4J2-330
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta8
Environment: JDK 1.7, Mongo Driver 2.11.2
Reporter: Ruslan
Assignee: Nick Williams
Seems like NoSQLAppender can't insert any log events to Mongo due to lack of
serializer for Level enum.
{quote}
2013-07-31 18:19:27,831 ERROR An exception occurred processing Appender
databaseAppender java.lang.IllegalArgumentException: can't serialize class
org.apache.logging.log4j.Level
at org.bson.BasicBSONEncoder._putObjectField(BasicBSONEncoder.java:270)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:174)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:120)
at com.mongodb.DefaultDBEncoder.writeObject(DefaultDBEncoder.java:27)
at com.mongodb.OutMessage.putObject(OutMessage.java:289)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:239)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:204)
at com.mongodb.DBCollection.insert(DBCollection.java:148)
at com.mongodb.DBCollection.insert(DBCollection.java:91)
at
org.apache.logging.log4j.core.appender.db.nosql.mongo.MongoDBConnection.insertObject(MongoDBConnection.java:61)
{quote}
Here is my config
{quote}
configuration status=WARN
appenders
NoSql name=databaseAppender suppressExceptions=true
MongoDb collectionName=applicationLog
factoryClassName=com.borsch.DBManager factoryMethodName=getNewMongoClient
writeConcernConstant=NONE username=root password=qwe/
/NoSql
/appenders
loggers
root level=error
appender-ref ref=databaseAppender/
/root
/loggers
/configuration
{quote}
For now I used following workaround (code is in Scala)
{code}
class LevelBSONEncoder extends org.bson.Transformer {
def transform(o: Any): AnyRef =
o match { case level: org.apache.logging.log4j.Level = new
java.lang.Integer(level.intLevel()) }
}
// which is used like this
org.bson.BSON.addEncodingHook(org.apache.logging.log4j.Level.ERROR.getClass,
new LevelBSONEncoder())
{code}
I think it should be done in appender.
--
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
[jira] [Updated] (LOG4J2-330) NoSQLAppender cannot insert log event to MongoDB
[
https://issues.apache.org/jira/browse/LOG4J2-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-330:
-
Fix Version/s: (was: 2.0-beta9)
NoSQLAppender cannot insert log event to MongoDB
Key: LOG4J2-330
URL: https://issues.apache.org/jira/browse/LOG4J2-330
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta8
Environment: JDK 1.7, Mongo Driver 2.11.2
Reporter: Ruslan
Assignee: Nick Williams
Seems like NoSQLAppender can't insert any log events to Mongo due to lack of
serializer for Level enum.
{quote}
2013-07-31 18:19:27,831 ERROR An exception occurred processing Appender
databaseAppender java.lang.IllegalArgumentException: can't serialize class
org.apache.logging.log4j.Level
at org.bson.BasicBSONEncoder._putObjectField(BasicBSONEncoder.java:270)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:174)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:120)
at com.mongodb.DefaultDBEncoder.writeObject(DefaultDBEncoder.java:27)
at com.mongodb.OutMessage.putObject(OutMessage.java:289)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:239)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:204)
at com.mongodb.DBCollection.insert(DBCollection.java:148)
at com.mongodb.DBCollection.insert(DBCollection.java:91)
at
org.apache.logging.log4j.core.appender.db.nosql.mongo.MongoDBConnection.insertObject(MongoDBConnection.java:61)
{quote}
Here is my config
{quote}
configuration status=WARN
appenders
NoSql name=databaseAppender suppressExceptions=true
MongoDb collectionName=applicationLog
factoryClassName=com.borsch.DBManager factoryMethodName=getNewMongoClient
writeConcernConstant=NONE username=root password=qwe/
/NoSql
/appenders
loggers
root level=error
appender-ref ref=databaseAppender/
/root
/loggers
/configuration
{quote}
For now I used following workaround (code is in Scala)
{code}
class LevelBSONEncoder extends org.bson.Transformer {
def transform(o: Any): AnyRef =
o match { case level: org.apache.logging.log4j.Level = new
java.lang.Integer(level.intLevel()) }
}
// which is used like this
org.bson.BSON.addEncodingHook(org.apache.logging.log4j.Level.ERROR.getClass,
new LevelBSONEncoder())
{code}
I think it should be done in appender.
--
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
[jira] [Commented] (LOG4J2-330) NoSQLAppender cannot insert log event to MongoDB
[
https://issues.apache.org/jira/browse/LOG4J2-330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13770507#comment-13770507
]
Nick Williams commented on LOG4J2-330:
--
**head desk**
That was a stupid mistake on my part. It's unfortunate that you weren't able to
verify this bug before beta9 was released. I could have gotten it fixed. But it
is what it is. The fix will be in 2.0.0.GA.
NoSQLAppender cannot insert log event to MongoDB
Key: LOG4J2-330
URL: https://issues.apache.org/jira/browse/LOG4J2-330
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta8
Environment: JDK 1.7, Mongo Driver 2.11.2
Reporter: Ruslan
Assignee: Nick Williams
Fix For: 2.0-beta9
Seems like NoSQLAppender can't insert any log events to Mongo due to lack of
serializer for Level enum.
{quote}
2013-07-31 18:19:27,831 ERROR An exception occurred processing Appender
databaseAppender java.lang.IllegalArgumentException: can't serialize class
org.apache.logging.log4j.Level
at org.bson.BasicBSONEncoder._putObjectField(BasicBSONEncoder.java:270)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:174)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:120)
at com.mongodb.DefaultDBEncoder.writeObject(DefaultDBEncoder.java:27)
at com.mongodb.OutMessage.putObject(OutMessage.java:289)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:239)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:204)
at com.mongodb.DBCollection.insert(DBCollection.java:148)
at com.mongodb.DBCollection.insert(DBCollection.java:91)
at
org.apache.logging.log4j.core.appender.db.nosql.mongo.MongoDBConnection.insertObject(MongoDBConnection.java:61)
{quote}
Here is my config
{quote}
configuration status=WARN
appenders
NoSql name=databaseAppender suppressExceptions=true
MongoDb collectionName=applicationLog
factoryClassName=com.borsch.DBManager factoryMethodName=getNewMongoClient
writeConcernConstant=NONE username=root password=qwe/
/NoSql
/appenders
loggers
root level=error
appender-ref ref=databaseAppender/
/root
/loggers
/configuration
{quote}
For now I used following workaround (code is in Scala)
{code}
class LevelBSONEncoder extends org.bson.Transformer {
def transform(o: Any): AnyRef =
o match { case level: org.apache.logging.log4j.Level = new
java.lang.Integer(level.intLevel()) }
}
// which is used like this
org.bson.BSON.addEncodingHook(org.apache.logging.log4j.Level.ERROR.getClass,
new LevelBSONEncoder())
{code}
I think it should be done in appender.
--
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
[jira] [Reopened] (LOG4J2-330) NoSQLAppender cannot insert log event to MongoDB
[
https://issues.apache.org/jira/browse/LOG4J2-330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reopened LOG4J2-330:
--
NoSQLAppender cannot insert log event to MongoDB
Key: LOG4J2-330
URL: https://issues.apache.org/jira/browse/LOG4J2-330
Project: Log4j 2
Issue Type: Bug
Components: Appenders
Affects Versions: 2.0-beta8
Environment: JDK 1.7, Mongo Driver 2.11.2
Reporter: Ruslan
Assignee: Nick Williams
Fix For: 2.0-beta9
Seems like NoSQLAppender can't insert any log events to Mongo due to lack of
serializer for Level enum.
{quote}
2013-07-31 18:19:27,831 ERROR An exception occurred processing Appender
databaseAppender java.lang.IllegalArgumentException: can't serialize class
org.apache.logging.log4j.Level
at org.bson.BasicBSONEncoder._putObjectField(BasicBSONEncoder.java:270)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:174)
at org.bson.BasicBSONEncoder.putObject(BasicBSONEncoder.java:120)
at com.mongodb.DefaultDBEncoder.writeObject(DefaultDBEncoder.java:27)
at com.mongodb.OutMessage.putObject(OutMessage.java:289)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:239)
at com.mongodb.DBApiLayer$MyCollection.insert(DBApiLayer.java:204)
at com.mongodb.DBCollection.insert(DBCollection.java:148)
at com.mongodb.DBCollection.insert(DBCollection.java:91)
at
org.apache.logging.log4j.core.appender.db.nosql.mongo.MongoDBConnection.insertObject(MongoDBConnection.java:61)
{quote}
Here is my config
{quote}
configuration status=WARN
appenders
NoSql name=databaseAppender suppressExceptions=true
MongoDb collectionName=applicationLog
factoryClassName=com.borsch.DBManager factoryMethodName=getNewMongoClient
writeConcernConstant=NONE username=root password=qwe/
/NoSql
/appenders
loggers
root level=error
appender-ref ref=databaseAppender/
/root
/loggers
/configuration
{quote}
For now I used following workaround (code is in Scala)
{code}
class LevelBSONEncoder extends org.bson.Transformer {
def transform(o: Any): AnyRef =
o match { case level: org.apache.logging.log4j.Level = new
java.lang.Integer(level.intLevel()) }
}
// which is used like this
org.bson.BSON.addEncodingHook(org.apache.logging.log4j.Level.ERROR.getClass,
new LevelBSONEncoder())
{code}
I think it should be done in appender.
--
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
[jira] [Commented] (LOG4J2-322) Endless loop in ThrowableProxy.getCurrentStack
[ https://issues.apache.org/jira/browse/LOG4J2-322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13761467#comment-13761467 ] Nick Williams commented on LOG4J2-322: -- Excellent! Good to hear. Endless loop in ThrowableProxy.getCurrentStack -- Key: LOG4J2-322 URL: https://issues.apache.org/jira/browse/LOG4J2-322 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.0-beta8 Environment: java version 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Reporter: Xavier Cho Assignee: Nick Williams Priority: Critical Fix For: 2.0-beta9 It seems that the getCallerClass method does not skip the frames correctly on OpenJDK, the ThrowableProxy falls into an endless loop which eventually lead to an OutOfMemoryError as it puts the same class into the stack over and over. -- 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
[jira] [Closed] (LOG4J2-322) Endless loop in ThrowableProxy.getCurrentStack
[ https://issues.apache.org/jira/browse/LOG4J2-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams closed LOG4J2-322. Endless loop in ThrowableProxy.getCurrentStack -- Key: LOG4J2-322 URL: https://issues.apache.org/jira/browse/LOG4J2-322 Project: Log4j 2 Issue Type: Bug Affects Versions: 2.0-beta8 Environment: java version 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Reporter: Xavier Cho Assignee: Nick Williams Priority: Critical Fix For: 2.0-beta9 It seems that the getCallerClass method does not skip the frames correctly on OpenJDK, the ThrowableProxy falls into an endless loop which eventually lead to an OutOfMemoryError as it puts the same class into the stack over and over. -- 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
[jira] [Resolved] (LOG4J2-394) ClassLoaderContextSelector logging WARN messages
[
https://issues.apache.org/jira/browse/LOG4J2-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-394.
--
Resolution: Duplicate
ClassLoaderContextSelector logging WARN messages
Key: LOG4J2-394
URL: https://issues.apache.org/jira/browse/LOG4J2-394
Project: Log4j 2
Issue Type: Bug
Components: Configurators
Affects Versions: 2.0-beta9
Reporter: Abhinav Shah
I am getting the following WARN message everytime my application logs
something.
{color:red}
WARN locateContext called with URI null. Existing LoggerContext has URI
classpath:log4j/local.log4j.xml
{color}
I traced this to ClassLoaderContextSelector -
{code}
if (ctx != null) {
if (ctx.getConfigLocation() == null configLocation != null) {
LOGGER.debug(Setting configuration to {}, configLocation);
ctx.setConfigLocation(configLocation);
} else if (ctx.getConfigLocation() != null
!ctx.getConfigLocation().equals(configLocation)) {
LOGGER.warn(locateContext called with URI {}. Existing
LoggerContext has URI {}, configLocation,
ctx.getConfigLocation());
}
return ctx;
}
{code}
[~ralph_go...@dslextreme.com] [~ralph.go...@dslextreme.com] Why are we
logging these WARN messages?
--
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
[jira] [Commented] (LOG4J2-394) ClassLoaderContextSelector logging WARN messages
[
https://issues.apache.org/jira/browse/LOG4J2-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759240#comment-13759240
]
Nick Williams commented on LOG4J2-394:
--
Because it is. This is caused by the classpath: URI scheme not being
recognized. That was reported in LOG4J-293 and fixed in beta9 (not released
yet).
ClassLoaderContextSelector logging WARN messages
Key: LOG4J2-394
URL: https://issues.apache.org/jira/browse/LOG4J2-394
Project: Log4j 2
Issue Type: Bug
Components: Configurators
Affects Versions: 2.0-beta9
Reporter: Abhinav Shah
I am getting the following WARN message everytime my application logs
something.
{color:red}
WARN locateContext called with URI null. Existing LoggerContext has URI
classpath:log4j/local.log4j.xml
{color}
I traced this to ClassLoaderContextSelector -
{code}
if (ctx != null) {
if (ctx.getConfigLocation() == null configLocation != null) {
LOGGER.debug(Setting configuration to {}, configLocation);
ctx.setConfigLocation(configLocation);
} else if (ctx.getConfigLocation() != null
!ctx.getConfigLocation().equals(configLocation)) {
LOGGER.warn(locateContext called with URI {}. Existing
LoggerContext has URI {}, configLocation,
ctx.getConfigLocation());
}
return ctx;
}
{code}
[~ralph_go...@dslextreme.com] [~ralph.go...@dslextreme.com] Why are we
logging these WARN messages?
--
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
[jira] [Commented] (LOG4J2-394) ClassLoaderContextSelector logging WARN messages
[
https://issues.apache.org/jira/browse/LOG4J2-394?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13759221#comment-13759221
]
Nick Williams commented on LOG4J2-394:
--
I'm betting this is a web application?
ClassLoaderContextSelector logging WARN messages
Key: LOG4J2-394
URL: https://issues.apache.org/jira/browse/LOG4J2-394
Project: Log4j 2
Issue Type: Bug
Components: Configurators
Affects Versions: 2.0-beta9
Reporter: Abhinav Shah
I am getting the following WARN message everytime my application logs
something.
{color:red}
WARN locateContext called with URI null. Existing LoggerContext has URI
classpath:log4j/local.log4j.xml
{color}
I traced this to ClassLoaderContextSelector -
{code}
if (ctx != null) {
if (ctx.getConfigLocation() == null configLocation != null) {
LOGGER.debug(Setting configuration to {}, configLocation);
ctx.setConfigLocation(configLocation);
} else if (ctx.getConfigLocation() != null
!ctx.getConfigLocation().equals(configLocation)) {
LOGGER.warn(locateContext called with URI {}. Existing
LoggerContext has URI {}, configLocation,
ctx.getConfigLocation());
}
return ctx;
}
{code}
[~ralph_go...@dslextreme.com] [~ralph.go...@dslextreme.com] Why are we
logging these WARN messages?
--
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
[jira] [Comment Edited] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[ https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756535#comment-13756535 ] Nick Williams edited comment on LOG4J2-293 at 9/3/13 11:45 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: 1. 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. 2. 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. 3. 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: 1) 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. 2) 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. 3) 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,
[jira] [Commented] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[ https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756535#comment-13756535 ] Nick Williams commented on LOG4J2-293: -- 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: 1) 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. 2) 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. 3) 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
[jira] [Comment Edited] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[ https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13756535#comment-13756535 ] Nick Williams edited comment on LOG4J2-293 at 9/3/13 11:45 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: 1. 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. 2. 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. 3. 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,
[jira] [Comment Edited] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[ https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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:
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755535#comment-13755535
]
Nick Williams commented on LOG4J2-359:
--
The problem is purely in documentation. The documentation just needs to be
changed to say that if you're running on a Servlet 3.0 or newer environment,
you don't have to manually initialize Log4j; one should _not_ put the Log4j
listener and filter in {{web.xml}} in a Servlet 3.0 or newer environment.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755546#comment-13755546
]
Nick Williams commented on LOG4J2-359:
--
Okay. I think I understand something that perhaps I didn't understand before.
It sounds like in a Servlet 3.0 environment with version 2.5 in web.xml, the
container calls {{onStartup}} on the initializer, but ignores the listener that
it adds programmatically. This behavior is confusing and arbitrary, and I
suspect other containers don't do it this exact same way.
Because of what I perceive to be a high likelihood of uncertainty in this
situation (Servlet 3.0+ container with 2.5- application), I think Abhinav's
patch is essentially correct. However, I would extend it further: the
initializer just needs to do _nothing_ in {{onStartup}} if the Servlet version
is less than 3. No adding a listener, no adding a filter. This way, the
behavior is guaranteed to be consistent across containers.
I'll make this change.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
[jira] [Resolved] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-359.
--
Resolution: Fixed
Fix Version/s: 2.0-beta9
Thanks for the patch. I tweaked it slightly to provide more extensive testing,
ensure the feature is used correctly, and ensure that it does nothing at all if
the application version is not 3.0 or greater. This is fixed in trunk. Can you
check out, build, verify and close?
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Fix For: 2.0-beta9
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755572#comment-13755572
]
Nick Williams commented on LOG4J2-359:
--
1. No, it would not be valid to specify the listener in {{web.xml}} in a
Servlet 3.0 application (the container doesn't matter, only the effective
application version).
2. It would also be completely unnecessary for them to manually specify the
listener in {{web.xml}} in a Servlet 3.0 application. Doing so would not
provide them any benefit, as they can customize the behavior using context
parameters without manually specifying the listener.
3. If they _did_ manually specify the listener in {{web.xml}}, it would not
have any negative impact on the application working correctly, because the
second call to initialize the {{Log4jWebInitializer}} is ignored. The problem
present in this bug was specifically that the _filter_ was being added twice
(which might not be immediately clear since the errors were all in the listener
and the initializer). It's important for the filter to be added so that it
executes before any filters defined in {{web.xml}}, so adding it in the
initializer is the safest route. In Servlet 2.5 applications the filter won't
be added in the initializer (and neither will the listener). In Servlet 3.0+
applications, Log4j makes in clear with a specific error message that the user
must not specify the filter in {{web.xml}}.
4. The initializer _must_ run automatically in a
{{ServletContainerInitializer}}. This is not an option. The reason for this is
that other {{ServletContainerInitializer}} implementations, such as the one
provided by Spring Framework, may trigger behavior that causes logging to take
place. If this happens before the initializer runs, all bets are off. Log4j
will not start up correctly and will cause errors on shutdown.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Fix For: 2.0-beta9
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
[jira] [Comment Edited] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755572#comment-13755572
]
Nick Williams edited comment on LOG4J2-359 at 8/31/13 6:24 PM:
---
1. No, it would not be valid to specify the listener in {{web.xml}} in a
Servlet 3.0 application (the container doesn't matter, only the effective
application version).
2. It would also be completely unnecessary for them to manually specify the
listener in {{web.xml}} in a Servlet 3.0 application. Doing so would not
provide them any benefit, as they can customize the behavior using context
parameters without manually specifying the listener.
3. If they _did_ manually specify the listener in {{web.xml}}, it would not
have any negative impact on the application working correctly, because the
second call to initialize the {{Log4jWebInitializer}} is ignored. The problem
present in this bug was specifically that the _filter_ was being added twice
(which might not be immediately clear since the errors were all in the listener
and the initializer). It's important for the filter to be added so that it
executes before any filters defined in {{web.xml}}, so adding it in the
initializer is the safest route. In Servlet 2.5 applications the filter won't
be added in the initializer (and neither will the listener). In Servlet 3.0+
applications, Log4j makes in clear with a specific error message that the user
must not specify the filter in {{web.xml}}.
4. The {{Log4jWebInitializer}} _must_ run automatically in a
{{ServletContainerInitializer}}. This is not an option. The reason for this is
that other {{ServletContainerInitializer}} implementations, such as the one
provided by Spring Framework, may trigger behavior that causes logging to take
place. If this happens before the initializer runs, all bets are off. Log4j
will not start up correctly and will cause errors on shutdown.
was (Author: beamerblvd):
1. No, it would not be valid to specify the listener in {{web.xml}} in a
Servlet 3.0 application (the container doesn't matter, only the effective
application version).
2. It would also be completely unnecessary for them to manually specify the
listener in {{web.xml}} in a Servlet 3.0 application. Doing so would not
provide them any benefit, as they can customize the behavior using context
parameters without manually specifying the listener.
3. If they _did_ manually specify the listener in {{web.xml}}, it would not
have any negative impact on the application working correctly, because the
second call to initialize the {{Log4jWebInitializer}} is ignored. The problem
present in this bug was specifically that the _filter_ was being added twice
(which might not be immediately clear since the errors were all in the listener
and the initializer). It's important for the filter to be added so that it
executes before any filters defined in {{web.xml}}, so adding it in the
initializer is the safest route. In Servlet 2.5 applications the filter won't
be added in the initializer (and neither will the listener). In Servlet 3.0+
applications, Log4j makes in clear with a specific error message that the user
must not specify the filter in {{web.xml}}.
4. The initializer _must_ run automatically in a
{{ServletContainerInitializer}}. This is not an option. The reason for this is
that other {{ServletContainerInitializer}} implementations, such as the one
provided by Spring Framework, may trigger behavior that causes logging to take
place. If this happens before the initializer runs, all bets are off. Log4j
will not start up correctly and will cause errors on shutdown.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Fix For: 2.0-beta9
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755625#comment-13755625
]
Nick Williams commented on LOG4J2-359:
--
So. Many. Questions. And stop editing comments hours later! :P ;-)
I'm going to address the ordering issue, first. You are correct that,
_according to the spec_, the order that SCIs are executed in is unspecified.
This is an oversight that I [intend to lobby hard to have corrected in Servlet
3.2|https://java.net/jira/browse/SERVLET_SPEC-79] (and judging by the Tomcat
mailing list, I'll have some backup). However, in practice, this is not
actually the case. If you read the responses to the message you link to, you
will see that Tomcat orders SCIs according to the web-fragment ordering. This
is legal, because the spec doesn't prohibit it, it just doesn't require it.
Furthermore, five of the eight major containers (Tomcat, TomEE, JBoss,
WebLogic, and WebSphere) order SCIs according to the web-fragment ordering.
After further inspection, it appears that GlassFish, Jetty, and Resin _do_
execute them in random order (*ugh*). However, with that said, this random
order is actually alphabetic by JAR name, and log4j*.jar comes before
spring*.jar. So, *most* users will *never* see a problem with ordering.
_(Yes, I'm operating under the assumption that Spring's SCI is the one we're
most concerned about. I've yet to see any other SCIs in any other third-party
libraries or in containers that could result in inadvertent initialization of
Log4j. I am, nevertheless, filing improvement requests with GlassFish, Jetty,
and Resin asking them to follow what other containers do.)_
With that out of the way, I'm not saying it's invalid to specify a servlet
context listener in the {{web.xml}} in Servlet 3.0+. I'm saying it's invalid
(but harmless) to re-define *Log4j's* listener in {{web.xml}} in Servlet 3.0+.
I'm not completely opposed to changing the exception to a warning, but I don't
agree with the idea, either. Added in the SCI, it ensures that the filter runs
before any filters in {{web.xml}}. It also ensures that it runs before any
filters in other SCIs (with the ordering issue kept in mind, of course). The
exception lets the user know in no uncertain terms that Log4j might not work
correctly because the filter wasn't defined early enough, and that they can
very simply fix the issue by taking the filter out of their {{web.xml}}. That's
my stance.
Web applications cannot define their own {{ServletContainerInitializer}}
implementations without putting them in a JAR file within WEB-INF/lib, so we
can't reasonably expect a user to do this. An annotation is a potential idea,
but I just don't see the necessity. The existing code _is_ capable of
initializing correctly. Just because there was a bug doesn't mean the whole
concept is fatally flawed. I *strongly* stand behind the idea of the user not
having to do *anything* other than add {{log4j2.xml}} to their application
unless they need to customize behavior (which they can do using the context
parameters; they don't need to override the existing initializer to do this).
If they _really_ need to stop Log4j from auto-initializing in Servlet 3.0+, we
don't have to provide a mechanism to support this. They can use
{{absolute-ordering}} in {{web.xml}} to exclude the Log4j web-fragment. I'm
okay with adding an example of doing this to the documentation.
I *do* agree that the initializer should not do anything if the Log4j JARs come
from the container and the application isn't actually using Log4j. What is the
*correct* way to detect this? I believe this is sufficient, but I could be
wrong:
- If the Log4j context parameters are specified, the application obviously
intends to use Log4j, so initialize it.
- If the Log4j context parameters are not specified but one of the standard
configuration files is present, the application obviously intends to use Log4j,
so initialize it.
- Otherwise, don't initialize Log4j.
If this is correct, this leads me to a question. How do I look for the
standard configuration without Log4j initializing the null or default
configuration if it doesn't find one?
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Fix For: 2.0-beta9
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet
[jira] [Reopened] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reopened LOG4J2-293:
--
As instructed in the mailing list conversation you linked to, can you enable
logging the effective {{web.xml}}? Then, attach both your _actual_ {{web.xml}}
and the _effective_ {{web.xml}}? Thanks.
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
[jira] [Resolved] (LOG4J2-322) Endless loop in ThrowableProxy.getCurrentStack
[
https://issues.apache.org/jira/browse/LOG4J2-322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-322.
--
Resolution: Fixed
Fix Version/s: 2.0-beta9
This has been fixed with trunk. Could you download the latest from source
control, compile it, and give it a try to see if it solves the problem for you?
I'd really hate to release these changes to find out you still have the problem.
Also, note that the changes I made are generally just a workaround for
Oracle/OpenJDK 7u25. The {{getCallerClass}} behavior is supposed to be restored
in 7u40, which comes out sometime mid-late September. In Java 8 it has been
removed completely, but that was already compensated for.
Endless loop in ThrowableProxy.getCurrentStack
--
Key: LOG4J2-322
URL: https://issues.apache.org/jira/browse/LOG4J2-322
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: java version 1.7.0_25
OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2)
OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode)
Reporter: Xavier Cho
Assignee: Nick Williams
Priority: Critical
Fix For: 2.0-beta9
It seems that the getCallerClass method does not skip the frames correctly on
OpenJDK, the ThrowableProxy falls into an endless loop which eventually lead
to an OutOfMemoryError as it puts the same class into the stack over and over.
--
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
[jira] [Resolved] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-359.
--
Resolution: Duplicate
Duplicate of LOG4J2-293.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004 Failures
were detected while initiating start task for application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149078 Stack trace
for message 149004
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at
[jira] [Issue Comment Deleted] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-359:
-
Comment: was deleted
(was: Duplicate of LOG4J2-293.)
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004 Failures
were detected while initiating start task for application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149078 Stack trace
for message 149004
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at
[jira] [Reopened] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams reopened LOG4J2-359:
--
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004 Failures
were detected while initiating start task for application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149078 Stack trace
for message 149004
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
[jira] [Comment Edited] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755244#comment-13755244
]
Nick Williams edited comment on LOG4J2-359 at 8/30/13 11:16 PM:
I shouldn't have closed this as duplicate. There is a separate issues here,
which needs to be resolved in documentation.
was (Author: beamerblvd):
Shouldn't have closed this as duplicate. There is a separate issues here,
which needs to be resolved in documentation.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT
[jira] [Resolved] (LOG4J2-357) log4jConfiguration via log4j.xml on classpath
[
https://issues.apache.org/jira/browse/LOG4J2-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-357.
--
Resolution: Duplicate
Duplicate of LOG4J2-293.
log4jConfiguration via log4j.xml on classpath
-
Key: LOG4J2-357
URL: https://issues.apache.org/jira/browse/LOG4J2-357
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Attachments: ConfigurationFactory.java, TestConfigurator.java
I am trying to configure log4j2 for a Web Application.
The documentation says -
{color:red}
If isLog4jContextSelectorNamed is not true, log4jConfiguration may be a
valid URI or a path to a file, or it may start with classpath: to denote a
file that can be found on the classpath.
{color}
Following is a snippet of my web.xml -
{code:xml}
context-param
param-namelog4jConfiguration/param-name
param-valueclasspath:log4j/dev.log4j.xml/param-value
/context-param
{code}
However, the file dev.log4j.xml is not getting picked up from classpath.
Spring has a similar feature which works fine with log4j 1.x. Please see
{code}
org.springframework.web.util.Log4jWebConfigurer
{code}
--
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
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755244#comment-13755244
]
Nick Williams commented on LOG4J2-359:
--
Shouldn't have closed this as duplicate. There is a separate issues here, which
needs to be resolved in documentation.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004 Failures
were detected while initiating start task for application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149078 Stack trace
for message 149004
[jira] [Commented] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755251#comment-13755251
]
Nick Williams commented on LOG4J2-293:
--
Thanks for looking into and, possibly (I haven't reviewed it yet), fixing this
issue. Such proposed patches should be attached as SVN diffs, not whole source
files. That way, it makes it easier for us to tell exactly what changed and
review the proposed patch.
Please use a command like {{svn diff LOG4J2-293.patch}} (from the trunk
directory) to generate a patch that can be properly vetted, and attach that
patch to this issue.
Thanks.
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
Attachments: ConfigurationFactory.java, 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
[jira] [Comment Edited] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755251#comment-13755251
]
Nick Williams edited comment on LOG4J2-293 at 8/30/13 11:22 PM:
Thanks for looking into and, possibly (I haven't reviewed it yet), fixing this
issue. Such proposed patches should be attached as SVN diffs, not whole source
files. That way, it makes it easier for us to tell exactly what changed and
review the proposed patch.
Please use a command like:
{code}$ svn diff LOG4J2-293.patch{code}
(from the trunk directory) to generate a patch that can be properly vetted, and
attach that patch to this issue.
Thanks.
was (Author: beamerblvd):
Thanks for looking into and, possibly (I haven't reviewed it yet), fixing
this issue. Such proposed patches should be attached as SVN diffs, not whole
source files. That way, it makes it easier for us to tell exactly what changed
and review the proposed patch.
Please use a command like {{svn diff LOG4J2-293.patch}} (from the trunk
directory) to generate a patch that can be properly vetted, and attach that
patch to this issue.
Thanks.
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
Attachments: ConfigurationFactory.java, 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
[jira] [Comment Edited] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[ https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755280#comment-13755280 ] Nick Williams edited comment on LOG4J2-293 at 8/31/13 12:09 AM: Your IDE has reformatted the JavaDoc and Java code in the file. This makes it very difficult to separate out the changes you made from the reformatting. Please correct this. Patches should not reformat code that doesn't change. You will likely need to disable this auto-reformatting in your IDE, or change the settings to reflect the Log4j coding standards (for example, 120-character lines, not 80-character lines as it appears your IDE is enforcing). was (Author: beamerblvd): Your IDE has reformatted the JavaDoc and Java code in the file. This makes in very difficult to separate out the changes you made from the reformatting. Please correct this. Patches should not reformat code that doesn't change. You will likely need to disable this auto-reformatting in your IDE, or change the settings to reflect the Log4j coding standards (for example, 120-character lines, not 80-character lines as it appears your IDE is enforcing). 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 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
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755281#comment-13755281
]
Nick Williams commented on LOG4J2-359:
--
Your IDE has reformatted the JavaDoc and Java code in the file. This makes in
very difficult to separate out the changes you made from the reformatting.
Please correct this. Patches should not reformat code that doesn't change. You
will likely need to disable this auto-reformatting in your IDE, or change the
settings to reflect the Log4j coding standards (for example, 120-character
lines, not 80-character lines as it appears your IDE is enforcing).
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
Log4jServletContainerInitializerTest.java
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
[jira] [Commented] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[ https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13755280#comment-13755280 ] Nick Williams commented on LOG4J2-293: -- Your IDE has reformatted the JavaDoc and Java code in the file. This makes in very difficult to separate out the changes you made from the reformatting. Please correct this. Patches should not reformat code that doesn't change. You will likely need to disable this auto-reformatting in your IDE, or change the settings to reflect the Log4j coding standards (for example, 120-character lines, not 80-character lines as it appears your IDE is enforcing). 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 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
[jira] [Resolved] (LOG4J2-358) NoSQLAppender using MongoDB provider ignores username and password attributes
[
https://issues.apache.org/jira/browse/LOG4J2-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams resolved LOG4J2-358.
--
Resolution: Fixed
Fixed in next release. You can also get the latest from trunk and compile
locally. Please verify and close. Thanks for reporting it!
NoSQLAppender using MongoDB provider ignores username and password attributes
-
Key: LOG4J2-358
URL: https://issues.apache.org/jira/browse/LOG4J2-358
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.0-beta7, 2.0-beta8
Reporter: Nick Williams
Assignee: Nick Williams
Priority: Critical
Fix For: 2.0-beta9
Original Estimate: 5m
Remaining Estimate: 5m
{{org.apache.logging.log4j.core.appender.db.nosql.mongo.MongoDBProvider#createNoSQLProvider}}
never uses the username and password attributes to authenticate against the
MongoDB database. It checks to ensure that the database is either already
authenticated or a username and password are provided, but then it never does
anything with the username and password.
--
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
[jira] [Commented] (LOG4J2-362) Add a diagram to the site that explains when to use which jar
[ https://issues.apache.org/jira/browse/LOG4J2-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742934#comment-13742934 ] Nick Williams commented on LOG4J2-362: -- That diagram is extremely clear and helpful, Remko. Great job! Just a few minor corrections: # API and Core JARs should be log4j-api-2.0.jar and log4j-core-2.0.jar, respectively. Not log4j-2.0-api.jar and log4j-2.0-core.jar. # For the API and Implementation you call them Log4j-2.0 API and Log4j-2.0 Implementation, but for the legacy API you call it Log4j 1.0 API. I would omit the hyphen there. But I do agree with the placement of the number on the name, in this diagram. After reviewing it, two things occurred to me: * Should we have the Log4j Tag Library JAR on here somewhere? I'm not convinced, just wondering what others think. * It looks like maybe there's a need for a jul-to-log4j-2.0 module? Having to jump through the jul-to-slf4j then slf4j-api then log4j-slf4j-impl-2.0 artifacts seems like asking for performance issues. Add a diagram to the site that explains when to use which jar - Key: LOG4J2-362 URL: https://issues.apache.org/jira/browse/LOG4J2-362 Project: Log4j 2 Issue Type: Bug Components: Documentation Affects Versions: 2.0-beta8 Reporter: Remko Popma Fix For: 2.0-beta9 Attachments: whichjar.png The log4j-2.0 download archive contains a number of jar files. It is not always immediately clear to new users which jar files they should use. A diagram should help to clarify this. Examples of the kind of diagram intended: http://www.slf4j.org/legacy.html http://wiki.apache.org/tomcat/FAQ/Logging -- 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
[jira] [Commented] (LOG4J2-362) Add a diagram to the site that explains when to use which jar
[ https://issues.apache.org/jira/browse/LOG4J2-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742948#comment-13742948 ] Nick Williams commented on LOG4J2-362: -- Looks better! I think JIRA allows you to mark attachments as obsolete (and it puts a line through them, but doesn't delete them for historical purposes). Can you do this for the original two attachments? Add a diagram to the site that explains when to use which jar - Key: LOG4J2-362 URL: https://issues.apache.org/jira/browse/LOG4J2-362 Project: Log4j 2 Issue Type: Bug Components: Documentation Affects Versions: 2.0-beta8 Reporter: Remko Popma Fix For: 2.0-beta9 Attachments: whichjar-1.png, whichjar.png, whichjar-slf4j-1.png, whichjar-slf4j.png The log4j-2.0 download archive contains a number of jar files. It is not always immediately clear to new users which jar files they should use. A diagram should help to clarify this. Examples of the kind of diagram intended: http://www.slf4j.org/legacy.html http://wiki.apache.org/tomcat/FAQ/Logging -- 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
[jira] [Commented] (LOG4J2-362) Add a diagram to the site that explains when to use which jar
[
https://issues.apache.org/jira/browse/LOG4J2-362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742955#comment-13742955
]
Nick Williams commented on LOG4J2-362:
--
There are actually several feature requests in JIRA's JIRA (is that like
inception?) to support attachment obsolescing. However, I did find this helpful
tidbit on a mailing list:
{quote}Trick: upload the file with exactly the same name, then the latest one
will be marked as latest (in mouse-over baloon), and earlier versions will be
shown in gray.{quote}
And this helpful tidbit on a JIRA, directly from a JIRA developer:
{quote}At the moment JIRA does allow one to attach files with the same name to
the issue and JIRA greys out the older files with the same name, such that
visually one can tell which attachment is the newest. Does this work for
you?{quote}
Try that?
Add a diagram to the site that explains when to use which jar
-
Key: LOG4J2-362
URL: https://issues.apache.org/jira/browse/LOG4J2-362
Project: Log4j 2
Issue Type: Bug
Components: Documentation
Affects Versions: 2.0-beta8
Reporter: Remko Popma
Fix For: 2.0-beta9
Attachments: whichjar-1.png, whichjar-2.png, whichjar.png,
whichjar-slf4j-1.png, whichjar-slf4j.png, whichjar.xlsx
The log4j-2.0 download archive contains a number of jar files.
It is not always immediately clear to new users which jar files they should
use. A diagram should help to clarify this.
Examples of the kind of diagram intended:
http://www.slf4j.org/legacy.html
http://wiki.apache.org/tomcat/FAQ/Logging
--
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
[jira] [Commented] (LOG4J2-344) Log4j2 doesnt work with Weblogic 12c
[
https://issues.apache.org/jira/browse/LOG4J2-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742618#comment-13742618
]
Nick Williams commented on LOG4J2-344:
--
The stack trace in question can _*ONLY*_ happen if WebLogic is in violation of
the spec. WebLogic is either calling {{doFilter}} before it calls {{init}} or
calling {{doFilter}} after it calls {{destroy}}, both of which are illegal
behaviors. You need to contact WebLogic support for assistance.
Log4j2 doesnt work with Weblogic 12c
Key: LOG4J2-344
URL: https://issues.apache.org/jira/browse/LOG4J2-344
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: Windows XP SP 3
Reporter: Keir
I get a Context destroyed before it was initialized exception, the problem
seems to be that the servlet filters init method is not being called by
WebLogic, not sure why...
--
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
[jira] [Created] (LOG4J2-358) NoSQLAppender using MongoDB provider ignores username and password attributes
Nick Williams created LOG4J2-358:
Summary: NoSQLAppender using MongoDB provider ignores username and
password attributes
Key: LOG4J2-358
URL: https://issues.apache.org/jira/browse/LOG4J2-358
Project: Log4j 2
Issue Type: Bug
Components: Core
Affects Versions: 2.0-beta8, 2.0-beta7
Reporter: Nick Williams
Assignee: Nick Williams
Priority: Critical
Fix For: 2.0-beta9
{{org.apache.logging.log4j.core.appender.db.nosql.mongo.MongoDBProvider#createNoSQLProvider}}
never uses the username and password attributes to authenticate against the
MongoDB database. It checks to ensure that the database is either already
authenticated or a username and password are provided, but then it never does
anything with the username and password.
--
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
[jira] [Comment Edited] (LOG4J2-344) Log4j2 doesnt work with Weblogic 12c
[
https://issues.apache.org/jira/browse/LOG4J2-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742657#comment-13742657
]
Nick Williams edited comment on LOG4J2-344 at 8/16/13 10:20 PM:
I thought about it, but doing so makes me nervous. This would mask
implementation problems in the container. If thousands of Log4j users complain
to WebLogic because their applications won't work, such a bug is going to get
fixed really quickly...
I think we should probably contact Oracle and report the problem and see
whether we think they'll act on it in a reasonable timeframe before we make
such a move.
*Important*
I suppose it's _possible_ there's something wrong with
{{org.apache.logging.log4j.core.web.Log4jWebInitializerImpl#getLog4jWebInitializer(ServletContext)}},
such that it can return a {{null}} value, but:
# Reading the code again, I can't for the life of me understand how it could
possibly return {{null}}; and,
# If it did return {{null}}, we should also be seeing an NPE from line 52 in
{{init}}.
was (Author: beamerblvd):
I thought about it, but doing so makes me nervous. This would mask
implementation problems in the container. If thousands of Log4j users complain
to WebLogic because their applications won't work, such a bug is going to get
fixed really quickly...
I think we should probably contact Oracle and report the problem and see
whether we think they'll act on it in a reasonable timeframe before we make
such a move.
*Important*
I suppose it's _possible_ there's something wrong with
{{org.apache.logging.log4j.core.web.Log4jWebInitializerImpl#getLog4jWebInitializer(ServletContext)}},
such that it can return a {{null}} value, but:
# Reading the code a again, I can't for the life of me understand how it could
possibly return {{null}}; and,
# If it did return {{null}}, we should also be seeing an NPE from line 52 in
{{init}}.
Log4j2 doesnt work with Weblogic 12c
Key: LOG4J2-344
URL: https://issues.apache.org/jira/browse/LOG4J2-344
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: Windows XP SP 3
Reporter: Keir
I get a Context destroyed before it was initialized exception, the problem
seems to be that the servlet filters init method is not being called by
WebLogic, not sure why...
--
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
[jira] [Commented] (LOG4J2-344) Log4j2 doesnt work with Weblogic 12c
[
https://issues.apache.org/jira/browse/LOG4J2-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742657#comment-13742657
]
Nick Williams commented on LOG4J2-344:
--
I thought about it, but doing so makes me nervous. This would mask
implementation problems in the container. If thousands of Log4j users complain
to WebLogic because their applications won't work, such a bug is going to get
fixed really quickly...
I think we should probably contact Oracle and report the problem and see
whether we think they'll act on it in a reasonable timeframe before we make
such a move.
*Important*
I suppose it's _possible_ there's something wrong with
{{org.apache.logging.log4j.core.web.Log4jWebInitializerImpl#getLog4jWebInitializer(ServletContext)}},
such that it can return a {{null}} value, but:
# Reading the code a again, I can't for the life of me understand how it could
possibly return {{null}}; and,
# If it did return {{null}}, we should also be seeing an NPE from line 52 in
{{init}}.
Log4j2 doesnt work with Weblogic 12c
Key: LOG4J2-344
URL: https://issues.apache.org/jira/browse/LOG4J2-344
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: Windows XP SP 3
Reporter: Keir
I get a Context destroyed before it was initialized exception, the problem
seems to be that the servlet filters init method is not being called by
WebLogic, not sure why...
--
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
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742668#comment-13742668
]
Nick Williams commented on LOG4J2-359:
--
Thanks for the thorough bug report. This may simply be a documentation issue.
After re-reading the relevant part of the spec, it would seem that Servlet 3.0+
containers must invoke any {{Log4jServletContainerInitializer}}s even if the
web-app version is 2.5. This seems like a bad decision on the part of the spec
committee, but if it's the case the documentation will have to be refactored. I
need to discuss it with some fellow Java EE experts and confirm my suspicions.
In the meantime, can you take the {{listener}}, {{filter}}, and
{{filter-mapping}} out of your deployment descriptor and see if it starts
working? Note that you might starting seeing a different error
({{NullPointerException}}) due to bug LOG4J2-344.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
[jira] [Updated] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Williams updated LOG4J2-359:
-
Assignee: Nick Williams
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004 Failures
were detected while initiating start task for application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149078 Stack trace
for message 149004
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
[jira] [Comment Edited] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742668#comment-13742668
]
Nick Williams edited comment on LOG4J2-359 at 8/16/13 10:27 PM:
Thanks for the thorough bug report. This may simply be a documentation issue.
After re-reading the relevant part of the spec, it would seem that Servlet 3.0+
containers must invoke any {{Log4jServletContainerInitializer}} implementations
even if the web-app version is 2.5. This seems like a bad decision on the part
of the spec committee, but if it's the case the documentation will have to be
refactored. I need to discuss it with some fellow Java EE experts and confirm
my suspicions.
In the meantime, can you take the {{listener}}, {{filter}}, and
{{filter-mapping}} out of your deployment descriptor and see if it starts
working? Note that you might starting seeing a different error
({{NullPointerException}}) due to bug LOG4J2-344.
was (Author: beamerblvd):
Thanks for the thorough bug report. This may simply be a documentation
issue. After re-reading the relevant part of the spec, it would seem that
Servlet 3.0+ containers must invoke any {{Log4jServletContainerInitializer}}s
even if the web-app version is 2.5. This seems like a bad decision on the part
of the spec committee, but if it's the case the documentation will have to be
refactored. I need to discuss it with some fellow Java EE experts and confirm
my suspicions.
In the meantime, can you take the {{listener}}, {{filter}}, and
{{filter-mapping}} out of your deployment descriptor and see if it starts
working? Note that you might starting seeing a different error
({{NullPointerException}}) due to bug LOG4J2-344.
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
[jira] [Commented] (LOG4J2-344) Log4j2 doesnt work with Weblogic 12c
[
https://issues.apache.org/jira/browse/LOG4J2-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742672#comment-13742672
]
Nick Williams commented on LOG4J2-344:
--
Keir, just for kicks, can you also post your {{web.xml}} configuration? It's
_possible_ this is related to LOG4J2-359.
Log4j2 doesnt work with Weblogic 12c
Key: LOG4J2-344
URL: https://issues.apache.org/jira/browse/LOG4J2-344
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Environment: Windows XP SP 3
Reporter: Keir
I get a Context destroyed before it was initialized exception, the problem
seems to be that the servlet filters init method is not being called by
WebLogic, not sure why...
--
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
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with web-app version 2.5
[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13742680#comment-13742680
]
Nick Williams commented on LOG4J2-359:
--
Oh. Haha. I missed that part, somehow. Thanks!
Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
web-app version 2.5
-
Key: LOG4J2-359
URL: https://issues.apache.org/jira/browse/LOG4J2-359
Project: Log4j 2
Issue Type: Bug
Affects Versions: 2.0-beta8
Reporter: Abhinav Shah
Assignee: Nick Williams
I have Weblogic 12c running. My web-app is version 2.5.
Following is a snippet from my web.xml
{code:xml}
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
id=WebApp_ID version=2.5
display-namepec-service/display-name
context-param
param-namelog4jConfiguration/param-name
param-valuefile:/C:/log4j/dev.log4j.xml/param-value
/context-param
listener
listener-classorg.apache.logging.log4j.core.web.Log4jServletContextListener/listener-class
/listener
filter
filter-namelog4jServletFilter/filter-name
filter-classorg.apache.logging.log4j.core.web.Log4jServletFilter/filter-class
/filter
filter-mapping
filter-namelog4jServletFilter/filter-name
url-pattern/*/url-pattern
dispatcherREQUEST/dispatcher
dispatcherFORWARD/dispatcher
dispatcherINCLUDE/dispatcher
dispatcherERROR/dispatcher
/filter-mapping
/web-app
{code}
However, on my server startup I am getting the following error -
{code}
Aug 16, 2013 3:12:32 PM PDT Warning HTTP BEA-101162 User defined
listener org.apache.logging.log4j.core.web.Log4jServletContextListener
failed: java.lang.IllegalStateException: Context destroyed before it was
initialized..
java.lang.IllegalStateException: Context destroyed before it was initialized.
at
org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
at
weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
at
weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
at
weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149265 Failure
occurred in the execution of deployment request with ID 1376691143681 for
task 2. Error is: weblogic.application.ModuleException
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
at
weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
at
weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
Truncated. see log file for complete stacktrace
Caused By: java.lang.NullPointerException
at
org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
at
weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
at
weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
at
weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
Truncated. see log file for complete stacktrace
Aug 16, 2013 3:12:32 PM PDT Error Deployer BEA-149202 Encountered an
exception while attempting to commit the 7 task for the application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149004 Failures
were detected while initiating start task for application
_auto_generated_ear_.
Aug 16, 2013 3:12:32 PM PDT Warning Deployer BEA-149078 Stack trace
for message 149004
weblogic.application.ModuleException
at
weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
at
[jira] [Resolved] (LOG4J2-339) Infinit loop in ThrowableProxy
[ https://issues.apache.org/jira/browse/LOG4J2-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Williams resolved LOG4J2-339. -- Resolution: Duplicate Infinit loop in ThrowableProxy -- Key: LOG4J2-339 URL: https://issues.apache.org/jira/browse/LOG4J2-339 Project: Log4j 2 Issue Type: Bug Components: Core Affects Versions: 2.0-beta7, 2.0-beta8 Environment: java version 1.7.0_25 OpenJDK Runtime Environment (IcedTea 2.3.10) (7u25-2.3.10-1ubuntu0.13.04.2) OpenJDK 64-Bit Server VM (build 23.7-b01, mixed mode) Reporter: Alexandr Dorogikh My issue has some relation to LOG4J2-245 but now when I trying to use catching()/error() with exception that has empty stack trace I trapped into infinit loop at /lib/log4j-core-2.0-beta7-sources.jar!/org/apache/logging/log4j/core/impl/ThrowableProxy.java:296 Screenshot http://uaimage.com/image/8338250d -- 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
[jira] [Commented] (LOG4J2-293) classloader URI scheme broken or insufficient when using Log4jContextListener
[
https://issues.apache.org/jira/browse/LOG4J2-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13728557#comment-13728557
]
Nick Williams commented on LOG4J2-293:
--
# Just to double-check, you're using Beta8, right?
# What exact version of Tomcat are you using?
# Attach your {{web.xml}} file, please.
# Go through all of the JARs in your application's {{/WEB-INF/lib}} directory
and find any and all JARs (other than log4j) that contain a
{{/META-INF/web-fragment.xml}} file. Post the names of those JARs and the
contents of their corresponding {{web-fragment.xml}} files.
# You have read [this
documentation|http://logging.apache.org/log4j/2.x/manual/webapp.html], correct?
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
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
