Changing application context path leads to using different (unknown) logging configuration - spring

Setup:
Tomcat 6.0.16
Struts 2.1.6
Apache Commons Logging 1.0.4
Log4J 1.2.17
What I did:
Change in server.xml:
<Context path="/" .../></Context>
to
<Context path="/shop" .../></Context>
The issues:
Everything in the application is working fine (on the first glance). All links are correct and working etc.
Now I discovered that the Loggers using Commons Logging (with Log4J) (usually the Loggers in Spring, Struts and OGNL) are using a different logger configuration than the default used before. Loggers using Log4J directly in the application are working fine with this configuration.
For debugging purpose I have a JSP listing all the loggers with:
Logger.getRootLogger().getLoggerRepository( ).getCurrentLoggers()
But the "commons logging logger" are not listed anymore, although I could verify that they exist if I debug the code.
The question:
How do I find the other configuration/root logger?
Do I have to change anything in the struts configuration (or somewhere else) in relation to the context path change?
Any ideas what the issue might be here?
Edit: I'm getting closer:
The platform I am using is loading a minimal logging at start up. Before changing the context the advanced logging was loaded right afterwards and everything was fine. For some reason the listener of the web.xml (Spring initialization, etc.) is now running before the advanced logging is loaded. These classes are using the apache commons logging api and get loggers assigned basing on the simple root logger. Right afterwards the root logger is replace by the platform but the commons loggers are not updated with the new configuration.
New question:
As I stated below, changing anything in the platform is no option. So why did the listener run earlier when I change the context and how can I prevent this.

For the sake of the moment Apache Tomcat uses JDK logging. If you didn't place commons-logging.properties file to your source dir the default logger using commons logging will be log4j. Anyway the Tomcat will not use that logging because it needs a special configuration to tell it to use log4j.
The root logger is what you use in the log4j configuration. For example
log4j.rootLogger=ERROR,Console
Changing context path is nothing related to the logging used by application.
I didn't see any issue with logging rather that in recent releases regarding implementation priority.

The logging creates a dependency between multiple tomcat web application and due this fact requires a specific order of loading this modules. Renaming the context to "/shop" leads to an other order as StandardContext.filterDefs is a simple HashMap and does not preserve the order of the server.xml.
I could fix my issues in running the required steps in a listener.
web.xml
<listener>
<listener-class>com.[...].InitListener</listener-class>
</listener>
InitListener.java
package com.[...];
public class InitListener
{
static
{
// init Log4J, etc.
}
}
{code}
(Btw. Listener order should be identical to the web.xml)

Related

LegacyCookieProcessor in standalone Tomcat and Spring Boot [duplicate]

My code is working on tomcat 8 version 8.0.33 but on 8.5.4 i get :
An invalid domain [.mydomain] was specified for this cookie.
I have found that Rfc6265CookieProcessor is introduced in tomcat 8 latest versions.
It says on official doc that this can be reverted to LegacyCookieProcessor in context.xml but i don't know how.
Please let me know how to do this.
Thanks
You can try in context.xml
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
reference:
https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html
Case 1: You are using Standalone Tomcat & have access to change files in tomcat server
Please follow answer by #linzkl
Case 2: You are using Standalone Tomcat but you don't have access to change files in tomcat server
Create a new file called context.xml under src/main/webapp/META-INF folder in your application & paste the content given below
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>WEB-INF/tomcat-web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
</Context>
When you deploy your application in Standalone Tomcat, the context.xml file you placed under META-INF folder will override the context.xml file given in tomcat/conf/context.xml
Note: If you are following this solution, you have to do it for every single application because META-INF/context.xml is application specific
Case 3: You are using Embedded Tomcat
Create a new bean for WebServerFactoryCustomizer
#Bean
WebServerFactoryCustomizer<TomcatServletWebServerFactory> cookieProcessorCustomizer() {
return new WebServerFactoryCustomizer<TomcatServletWebServerFactory>() {
#Override
void customize(TomcatServletWebServerFactory tomcatServletWebServerFactory) {
tomcatServletWebServerFactory.addContextCustomizers(new TomcatContextCustomizer() {
#Override
public void customize(Context context) {
context.setCookieProcessor(new LegacyCookieProcessor());
}
});
}
};
}
Enabling the LegacyCookieProcessor which is used in previous versions of Tomcat has solved the problem in my application. As linzkl mentioned this is explained in Apache's website https://tomcat.apache.org/tomcat-8.0-doc/config/cookie-processor.html.
The reason is that the new version of Tomcat does not understand the . (dot) in front of the domain name of the Cookie being used.
Also, make sure to check this post when you are using Internet Explorer. Apparently, it's very likely to break.
You can find context.xml in the following path.
tomcat8/conf/context.xml
<?xml version="1.0" encoding="UTF-8”?>
<!-- The contents of this file will be loaded for each web application —>
<Context>
<!-- Default set of monitored resources. If one of these changes, the -->
<!-- web application will be reloaded. -->
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<WatchedResource>${catalina.base}/conf/web.xml</WatchedResource>
<!-- Uncomment this to disable session persistence across Tomcat restarts -->
<!-- <Manager pathname="" /> -->
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor"/>
</Context>
The problem is still with Tomcat9. Same process need to follow for Tomcat 9 to set the class.
Add the class in context.xml file.
If you are using eclipse to run the application, need to set in the context.xml file in the server folder. Refer the below screenshot for more reference.
Hope this helps someone.
SameSite issue in tomcat version < 8.5.47 has resolved
In Tomcat 8.5.47 and bellow (Tomcat 8 versions), setting CookieProcessor tag to enable same site (as given bellow) in context.xml does not work due to a bug in Tomcat.
<CookieProcessor className="org.apache.tomcat.util.http.LegacyCookieProcessor" sameSiteCookies="none" />
If you find in this situation where it is not a easy thing to upgrade tomcat immediately (which I faced recently), or if you find any other case where you just need custom processing in cookies; You can write your own CookieProcessor class to get around.
Please find a custom CookieProcessor implementation and details of it's deployment steps here.
In my case I wrote a custom CookieProcessor based on LegacyCookieProcessor source code that allows tomcat 8.5.47 to enable SameSite attribute in cookies.
As mentioned by #atul, this issue persists in Tomcat 9. It will most likely persist moving forward with all future versions of Tomcat, since this is the new standard.
Using the legacy cookie processor (by adding the line above to the context.xml file) is working well for us. However, the true 'fix' is to adjust how your cookie is formed in the first place. This will need to be done in your application, not in Tomcat.
The new cookie processor does not allow the domain to start with a . (dot). Adjusting your cookie (if possible) to start with a value other than that will fix this problem without reverting to the old, legacy cookie processor.
Also, it should be obvious, but I didn't see it mentioned above: after updating the context.xml file, you need to restart the Tomcat service for the change to take effect.
Cheers!

Change PDFBox logging level using logback

I have a java app that is running on spring boot.
I'm using tika which in turn uses pdfbox.
I'm using logback as my logging implementation with slf4j.
I know that pdfbox uses apache commons logging.
I'm trying to disable the change the logging level to FATAL like so
<logger name="org.apache.pdfbox" level="FATAL"/>
The problem is that it still doesn't change the level.
I've run this with a debugger. I'm inspecting the logger that pdfbox uses and the results are
result = SLF4JLocationAwareLog
name = org.apache.pdfbox.util.PDFStreamEngine
logger.level = null
logger.loggerContext = ch.qos.logback.classic.LoggerContext[default]
By logger context, I understand that it is indeed using logback, but the configs are not present.
I'll answer my own question and hope that someone will find it useful.
The reason that the logger.level was null is because I didn't specify anything, so it got it from the parent logger. The FATAL didn't work because the highest level is not FATAL but ERROR.
http://logback.qos.ch/apidocs/ch/qos/logback/classic/Level.html
When I changed it to error everything worked as expected.

How do I turn debug logging off, in log4j, for docx4j

I receive the following message when I deploy my maven/spring application on jboss as7 and attempt to upload a docx file. The message is displayed within the body of the uploaded file when I view it in the app's WYSIWIG editor. The message does not display when I run the app locally on jetty. I included the log4j and docx4j property files. I'm not sure what property would allow me to toggle the debug logging for the docx4j class mentioned in the error and so far I've come up empty on web searches. BTW, my app is not using a log4j/docx4j xml file and from what I've read it's an either or setup. If I should switch to xml, then please let me know and please inform me of which property needs to be adjusted so I can clear this message.
TY
TO HIDE THESE MESSAGES, TURN OFF log4j debug level logging for org.docx4j.convert.out.html.HtmlExporterNG2
log4j.properties
log4j.rootLogger=ERROR,stdout
#Console Appender
log4j.appender.stdout=org.apache.log4j.ConsoleAppender
log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
log4j.appender.stdout.layout.ConversionPattern=[%5p] [%t %d{hh:mm:ss}] (%F:%M:%L) %m%n
#Custom assignments
log4j.logger.Controllers=DEBUG,stdout
log4j.logger.Entities=DEBUG,stdout
log4j.logger.Models=DEBUG,stdout
#Disable additivity
log4j.additivity.Controllers=false
log4j.additivity.Entities=false
log4j.additivity.Models=false
docx4j.properties
# Page size: use a value from org.docx4j.model.structure.PageSizePaper enum
# eg A4, LETTER
docx4j.PageSize=LETTER
# Page size: use a value from org.docx4j.model.structure.MarginsWellKnown enum
docx4j.PageMargins=NORMAL
docx4j.PageOrientationLandscape=false
# Page size: use a value from org.pptx4j.model.SlideSizesWellKnown enum
# eg A4, LETTER
pptx4j.PageSize=LETTER
pptx4j.PageOrientationLandscape=false
# These will be injected into docProps/app.xml
# if App.Write=true
docx4j.App.write=true
docx4j.Application=docx4j
docx4j.AppVersion=2.7
# of the form XX.YYYY where X and Y represent numerical values
# These will be injected into docProps/core.xml
docx4j.dc.write=true
docx4j.dc.creator.value=docx4j
docx4j.dc.lastModifiedBy.value=docx4j
#
#docx4j.McPreprocessor=true
# If you haven't configured log4j yourself
# docx4j will autoconfigure it. Set this to true to disable that
docx4j.Log4j.Configurator.disabled=true
We had a similar issue while using docx4j with Spring Boot.
Since spring-boot-starter-logging auto-configures logback-classic which is used as implementation for loggers, it comes to just setting correct level for package. In our case we didn't need any logging from docx4j therefore adding below line to application.properties disabled whole output from 'docx4j':
logging.level.org.docx4j=OFF
If you specifically need to disable console print of document, then you need to set turn off log level on this particular file:
logging.level.org.docx4j.model.datastorage.migration.VariablePrepare=OFF
EDIT: I know this topic is old but there are very limited sources targeting this topic while using spring boot. I hope this helps someone in future.
I'm not sure how docx4j configures log4j, but you could try changing the docx4j.Log4j.Configurator.disabled=true to false instead.
If that doesn't work you might want to try excluding the servers log4j implementation. You can add a jboss-deployment-structure.xml that excludes log4j.
change the rootCategory Level from DEBUG to OFF in your log4j.properties or log4j.xml file
log4j.rootCategory=OFF, SymbolicNameForAppender
I was able to disable the logging output with the following (using docx4j 2.8.1):
Docx4jProperties.getProperties().setProperty(
"docx4j.Log4j.Configurator.disabled", "true");
Log4jConfigurator.configure();
Note that without the second statement, the logging was not suppressed.
Use following code:
Docx4jProperties.getProperties().setProperty("docx4j.Log4j.Configurator.disabled", "true");
Log4jConfigurator.configure();
org.docx4j.convert.out.pdf.viaXSLFO.Conversion.log.setLevel(Level.OFF);
Use this:
LogManager.getLogger("org.docx4j").setLevel(Level.OFF);

log4j implementation in my spring webapp

i need to implement log4j on my spring webapp. I was trying in using log4j.xml and then calling it in my java file private static Logger logger = Logger.getLogger(IndexController.class);
Somewat like above and then logger.info("Index Controller done successfully");
but it didnt worked out.
So, please get me some steps and where to keep what to make it work. I have kept my log4j.xml inside WEB-INF folder.
Thanks in advance!!!
For the default setup, ensure that the log4j.xml file is at the root of the classpath. Also, ensure that you have the log4j (and commons-logging) dependency.
We may need more information to really get this working with your particular setup.

Logging in spring 3.0 under glassfish?

I'm trying to debug why certain handlers in one of my controllers is not invoked by Spring's AnnotationMethodHandlerAdapter. I don't get any errors in Netbeans, just a 404 in the browser. I tried placing a breakpoint in one of my working controllers/handlers then walking up the chain to place a breakpoint in the dispatcher.
Netbeans shows me some funny method bodies:
protected ModelAndView invokeHandlerMethod(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception
{
//compiled code
throw new RuntimeException("Compiled Code");
}
which I suspect is caused by the AOP magiq. Undeterred, I tried to configure log4j to trace the calls and display any messages logged at debug level from the org.springframework.web.servlet.mvc.annotation package, but just by creating a log4j.properties file and putting in the classpath I get nothing more than the default "INFO:" level messages. Adding the context-param and listener in web.xml fails because the container can't find the log4j classes, even though they are there and even though I can add them again to the project.
So, the question is -- what do I need to do to get method traces (this could be done through AOP) and enhanced debugging (this definitely needs log4j) under Spring 3.0?
If I'm not mistaken Spring 3.X uses SLF4J for logging. Usually you would need to add SLF4J binding for your logging framework of choice - for example, for log4, slf4j-log4j12 jar should be present in classpath as well as log4j.jar and they better be proper versions - I found SLF4J to be picky about that. See more details here. Also don't forget log4j.xml config.

Resources