Log4j2 logging with Tomcat 9 web app
Hi,
My web app is based on Tomcat 9.0.45 server. I have migrated from Tomcat 7
to Tomcat 9 and from log4j 1.x to log4j 2.x.
I have updated the log4j2.properties as per log4j 2.x standard, still my
tomcat.log file is not getting generated and all the application log are
coming on console instead of redirecting this to tomcat.log file.
so 1.tomcat.log is not geting generated
2. all the contents are logging and showing on the application console
instead of getting this logged inside the tomcat.log file.
Tomcat 9.0.45 + log4j 2.14.1 is used.
I am also attaching my log4j property file. Please find this attached here.
Kindly suggest me the solution.
Thank you.
Ravi
#log4j.rootLogger=error, R
#log4j.appender.R=org.apache.log4j.RollingFileAppender
#log4j.appender.R.File=${catalina.base}/logs/tomcat.log
#log4j.appender.R.MaxFileSize=10MB
#log4j.appender.R.MaxBackupIndex=10
#log4j.appender.R.layout=org.apache.log4j.PatternLayout
#log4j.appender.R.layout.ConversionPattern=%p %t %c - %m%n
#log4j.logger.org.apache.catalina=error, R
#log4j.logger.org.apache.catalina.core.ContainerBase.[Catalina].[localhost]=error,
R
#log4j.logger.org.apache.catalina.core=error, R
#log4j.logger.org.apache.catalina.session=error, R
status = error
name = Log4j2PropertiesConfig
appender.rolling.type = RollingFile
appender.rolling.name = RollingFile
appender.rolling.fileName
=D:/TH512-15/administrator/domain/RD1/tomcat/logs/tomcat.log
appender.rolling.layout.type = PatternLayout
appender.rolling.layout.pattern =%p %t %c - %m%n
appender.rolling.policies.type = Policies
appender.rolling.policies.size.type = SizeBasedTriggeringPolicy
appender.rolling.policies.size.size=10MB
appender.rolling.strategy.type = DefaultRolloverStrategy
appender.rolling.strategy.max = 10
logger.rolling.name = org.apache.catalina
logger.rolling.level = error
logger.rolling.additivity = false
logger.rolling.appenderRef.rolling.ref = RollingFile
logger.rolling.name =
org.apache.catalina.core.ContainerBase.[Catalina].[localhost]
logger.rolling.level = error
logger.rolling.additivity = false
logger.rolling.appenderRef.rolling.ref = RollingFile
logger.rolling.name = org.apache.catalina.core
logger.rolling.level = error
logger.rolling.additivity = false
logger.rolling.appenderRef.rolling.ref = RollingFile
logger.rolling.name = org.apache.catalina.session
logger.rolling.level = error
logger.rolling.additivity = false
logger.rolling.appenderRef.rolling.ref = RollingFile
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Error that only occurs on mobile
First, understand that I have even less involvement in development of our mobile apps than I do in the development of our Tomcat webapp. So I'm grasping at straws here. All I know is that the mobile apps work through the webapp. It seems that at a specific customer installation, when the mobile app (both Apple and Android) tries to access our BIRT-based dashboards, they don't work (the dashboards work fine from a desktop browser). We recently updated that customer from 7.0.93 to 8.5.68, and installed the latest version of our webapp. The error message that appears on Android is in the form: The webpage at https://[very long url omitted] could not be loaded because: net::ERR_BLOCKED_BY_RESPONSE I will note that we do have the httpHeaderSecurity filter enabled, with an antiClickJackingOption of SAMEORIGIN. Does anybody here have any insights that I might pass on to the webapp/mobile team? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: request.getPathInfo() Question
On 19/07/2021 20:55, Jerry Malcolm wrote: I have a servlet in the ROOT context mapped to "/". I'm using request.getPathInfo() to get everything after the ".com/" in the URL. But no matter what is added to the url after .com/, getPathInfo() always returns null. I printed out getRequestURL(), and it shows everything. I can parse the path out of getRequestURL(). But I'm curious why getPathInfo() is always null. The docs say it returns null if there's no path info. But that's not the case. I'm on TC 9.0.16. Tomcat's behaviour is correct since the servlet is the "default" servlet. Please see section 12.2 of the Servlet 4.0 specification. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Cache-Control for INTEGRAL transport guarantee?
On 19/07/2021 20:46, Mikael Sterner wrote: Hi! I can understand the motivation for adding a Cache-Control header for CONFIDENTIAL transport guarantees, as discussed in http://tomcat.10.x6.nabble.com/tomcat-8-0-jre8-user-data-constraint-CONFIDENTIAL-user-data-constraint-adds-Cache-Control-private-tp5077170p5077201.html But if the transport guarantee is only INTEGRAL (and there are no authorization constraints), wouldn't it make more sense to let the resource be fully cached? Probably. One use case would be a single-page app where some static resources never change (e.g. due to content hashes in their names). These resources would require data integrity, since it's important that the app logic and content cannot be modified in transit. But if the resources don't require authorization they aren't secret, so they don't require confidentiality. And since they never change, it's wasteful for the client to check with the server to validate its cache on every request. What I'm proposing, if the above makes sense, would be to add an additional criteria to the disableProxyCaching logic in AuthenticatorBase, that goes through the constraints array and checks if there are any authorization constraints or user data constraint with CONFIDENTIAL transport guarantee. If not, no cache control headers should be added. Static resources could then be configured with a transport guarantee of INTEGRAL and still redirect to a secure connector if needed, but retain full caching. Cache headers have been somewhat of a moving target with different browsers behaving in different ways at different times over the years. I wanted to review the current state of things before forming an opinion on this suggestion. I found the following the most useful: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Expires https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma I'm wondering if an alternative solution would be to move the code that sets "Expires: Thu, 01 Jan 1970 00:00:00 GMT" to the securePagesWithPragma section. If we are sending "Cache-control: private" then I don't, at the moment, see a need to force revalidation of that cached content on every request. That would leave the application free to set its own expires headers (or not) as it saw fit. Anyone using an HTTP/1.0 proxy would need to be using securePagesWithPragma anyway so would be unaffected by this. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
