In a previous release of JBoss EAP 6, logging profiles worked as expected for a servlet, but did not work for a JSP; all log messages from a JSP went to the system log context.
This issue presented because the class loader that was checked was `org.apache.jasper.servlet.JasperLoader` with a parent class loader of the class loader that was registered for the log context.
This issue has been resolved by adding an option to the log manager to recursively check a class loader's parent for a LogContext.
Description of problem:
Suppose the following logging-profile has been set in logging subsystem, and a web app has a proper entry in its MANIFEST.MF (Logging-Profile: logone). Then all messages via "com.example.logone" logger should go into a file, logone.log. It does so with a logger got in a servlet, but it doesn't work a logger got in a JSP.
<file relative-to="jboss.server.log.dir" path="logone.log"/>
Steps to Reproduce:
1. Set the logging-profile in the description to a standalone instance.
2. Deploy attached web app, logone/target/logone.war.
3. Access a servlet, curl http://localhost:8080/logone/HogeServlet. Its log message appears in standalone/log/logone.log, as expected.
4. Access a JSP, curl http://localhost:8080/logone/index.jsp. Its log message appears in standalone/log/server.log and CONSOLE, unexpectedly.
Log from the servlet goes to standalone/log/logone.log.
Log from the JSP goes to standalone/log/server.log.
Both log messages should go to standalone/log/logone.log.
Created attachment 825352 [details]
A maven project with a binary, target/logone.war.
Osamu Nagano <email@example.com> made a comment on jira WFLY-2524
Similar issue, but not sure if it is the same.
Looks like the issue is the class loader being checked is a org.apache.jasper.servlet.JasperLoader with a parent class loader of the class loader that was registered for the log context. I'm not sure what the fix is going to be ATM. I mainly just wanted to note the cause.
Could you please review the Doc Text draft I've added. Feel free to make any necessary changes as I had trouble parsing the issue.
Added a slight clarification to doc text.
This looks okay to me.
Verified with EAP 6.4.0.DR2.