I wish I could forward all requests completely to another server.
I was tasked with writing a web application that needs to forward a http request to each server after checking certain headers. Of course I can use a library like apache http client to reconstruct and send the data. But if you think about it, this is a very unreasonable and bad way. Suppose you need to forward a request that uploads a 100 mega file. To forward this, once the servlet receives it as an object, the server memory is already reduced. Couldn't Servlet Engine check and pass only a few headers and pass it in stream format? Even if it is not the above example, I think the servlet may have the ability to have it in a raw state or to return it, like the request strings sent to telnet. I think it would be great if this could be supported by the servlet engine itself. Thank you for reading!
How to pass the --enable-preview parameter when using JSVC?
Hello, When I deploy my war it produces the below error message, telling me to pass the "--enable-preview". I can add the "--enable-preview" to my tomcat start.sh script dev environment to resolve the problem. However, if I launch the production tomcat using the jsvc binary (to bind to port 443 instead of 8443), the JSVC binary doesn't seem to pass the "--enable-preview" parameter. What must I do to allow JSVC to accept and pass the "--enable-preview" parameter? apache-tomcat-9.0.27 jdk-13.0.1 18-Mar-2020 15:38:27.659 SEVERE [main] org.apache.catalina.core.StandardContext.filterStart Exception starting filter [FrameSecurityFilter] java.lang.UnsupportedClassVersionError: Preview features are not enabled for com/marsh/div/rock/emp/FrameSecurityFilter (class file version 57.65535). Try running with '--enable-preview' (unable to load class ..) BUT then if I try to add --enable-preview to the production JSVC script environment: "Invalid option --enable-preview Cannot parse command line arguments" Thank you for any and all help! Ken - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 3/18/20 1:16 AM, Olaf Kock wrote: Are you sure that this is for tomcat, not for your own application? Actually, since on-screen it looks like one of ours, I was already leaning to that conclusion, and had brought it to the attention of our webapp developer. Thanks for all the responses and clarifications. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Security audit raises questions (Tomcat 7.0.93)
Hi JHHL
> security audit on the Tomcat server we maintain
My condolences. :-) We're gone through several scans over the past couple
years too. Yeah, it's a pain.
If you can get the report details, it may provide enough info to pinpoint the
exact problems. Checkmarx scanning software does, I think.
Also, a strategy I found helpful was to reduce the "attack surface". Get rid
of anything flagged that you don't use rather than trying to fix the issues.
> First, it found a cross-site scripting vulnerability.
For scans of our systems, the XSS vulnerabilities were poorly protected JSP
expression language, uh, expressions. :-) Using standard tag libraries to
wrap ${expressions} helped. Also, defining a custom sanitize function used in
JSP pages like ${fn:escapeXml(param.xxx)} satisfied requirements in the
negotiation process.
Something we did not get around to was moving the JSP files to the
WebContent\WEB-INF folder so they could not be called directly with injected
malicious parameters.
> Second, it found the HTTP DELETE method enabled.
Do you need it? Can you disable it?
> Fourth, it found the HTTP OPTIONS method enabled.
Again, do you need it? Can you disable it?
> the click-jacking vulnerability came up [...] just now set up
> the filter and filter-mapping in conf/web.xml, so that is
> hopefully taken care of in the next restart.
+1 :-)
--
Cris Berneburg
CACI Lead Software Engineer
-Original Message-
From: James H. H. Lampert
Sent: Tuesday, March 17, 2020 6:05 PM
To: Tomcat Users List
Subject: Security audit raises questions (Tomcat 7.0.93)
Ladies and Gentlemen:
One of our customers did a security audit on the Tomcat server we maintain on
their system, and it found a few issues:
First, it found a cross-site scripting vulnerability.
Second, it found the HTTP DELETE method enabled.
Third, it found a click-jacking vulnerability.
Fourth, it found the HTTP OPTIONS method enabled.
Back in October, the click-jacking vulnerability came up on another customer
box; I've found the thread, and just now set up the filter and filter-mapping
in conf/web.xml, so that is hopefully taken care of in the next restart.
But I have no idea what to do about the cross-site scripting vulnerability, or
the DELETE and OPTIONS methods, and I'm having trouble understanding the
materials I've found.
--
JHHL
This electronic message contains information from CACI International Inc or
subsidiary companies, which may be company sensitive, proprietary, privileged
or otherwise protected from disclosure. The information is intended to be used
solely by the recipient(s) named above. If you are not an intended recipient,
be aware that any review, disclosure, copying, distribution or use of this
transmission or its contents is prohibited. If you have received this
transmission in error, please notify the sender immediately.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 3/17/20 18:31, James H. H. Lampert wrote: > > On 3/17/20 3:18 PM, Martynas Jusevičius wrote: >> why should DELETE or OPTIONS not be enabled? They are standard >> HTTP methods. > > True, but (quoting the audit report) >> . . . [DELETE] may allow a remote attacker to delete arbitrary >> files . . . . With (undue) respect to the auditors, using the SHUTDOWN method may allow a remote attacker to shut down your server while the DOWNLOAD_DATABASE method may allow an attacker to download your whole database. > and (again quoting the report) >> Web servers that respond to the OPTIONS HTTP method expose what >> other methods are supported by the web server, allowing attackers >> to narrow and intensify their efforts. The entire point of the OPTIONS method is to advertise what is allowed. There are other ways to discover what is allowed: simply try everything and see what works. OPTIONS is an optimization which is essentially required by some protocols (e.g. WebDAV). If you don't need it, you can disable it. IIRC, JSPs "allow" all methods but they all end up calling service(...) and doing whatever the JSP is supposed to do (which is almost always a GET or POST handler). So just because DELETE and/or OPTIONS don't cause any errors doesn't mean that DELETE will actually delete a file. You can put a filter in place to reject all such requests, but if your application needs them then it will break your application. If your application does not need them then they are harmless, assuming your application does not have any exploitable vulnerabilities. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5yHrEACgkQHPApP6U8 pFgJdw/7BU4ojwCGAgpdVtykssD/vm18P7rnnyKREIYzRm1lwB/fi/T2fh0pV/hT 9+kiXpF7IArNnXBS2JnHOfABFlxDqHZJ6UHH7nRnU/nMUyZw61pn8AioF4r7LlKP vQnF8fT5+n8evKPjHkUiJoRNyH0V4DATOR9fuk9+4sjMj4WO+7pWbYRq/TWVTfrn APceEqdmyBiSXTMbhfT+CRXOAK6WGe8aIuM43ebpMw5f2x+EZmdr8cgWYu+tpwVJ pYzdG52Qjv8XaBEEtvQCnQC6c51sQYwOJ1EsMXkhmrsB6oEPy0A+CPsmSe4fGjCK 85RpZLBhZDxu/ScJ75C+agesTBbM7KXFTgn06mP1L2iUJMg41lpYWv5pzsqDUF81 wT9je9dfa+87ud5d9FG6E+4p4O/y9Sy1DWax48SLJaunqEMxxtq2yQ9etoZdM02r IR3n9CO+9PI+DrdkI8vLKEPI6NZDlroz3uqSqkhngmiyot6WOTLXIRfAYM6868qq s818lxrTi1TFu4ikrW3k+GbU7Z1rIzGkGjPyYGZGevvNTWJ9YCyHec9YuRhc78/Z wSFKQ2DgLS5/vqtkQ2EIZY/b5sB5t0xu0+0pQrWV0Tgak+788CPETe3nA5jaIQE1 yHNHpTTT2PU5oW6SaPvl5uNoGwkxIBHwjFyhWlf6+4GW/nGuXpY= =3Vwe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Security audit raises questions (Tomcat 7.0.93)
On 18/03/2020 00:04, James H. H. Lampert wrote: > On 3/17/20 3:50 PM, Mark Thomas wrote: >> The XXS might be valid. I assume the tool provided a sample URL you >> could use to validate the finding. That should point you in the right >> direction but feel free to ask here if more help is required. > Near as I can tell, it did but it didn't provide a sample URL. > > Note that *all* I have is a PDF of the report, and I think the URL may > have gotten mangled by spanning a page-break. I've posted a screenshot > (with identifying information redacted) of what I'm looking at in the > report: > > https://www.flickr.com/gp/64159238@N03/02i78o I'll agree with Olaf. That doesn't look like a Tomcat file. Tomcat's error.jsp doesn't have a from parameter. > > As to DELETE and OPTIONS, you get no argument from me about whether a > DELETE will actually *do* anything (I've got a query out to our web > developer on that), and on restricting OPTIONS being a case of "Security > by obscurity"; however, this is a case of "The Customer is Always Right." > > I found a page on disabling HTTP methods with a security constraint: > > https://www.techstacks.com/howto/disable-http-methods-in-tomcat.html The issue with that constraint is that it blacklists unwanted methods rather than whitelisting acceptable ones. I'd go with something like: Limit methods /* GET HEAD POST > But I'm not sure (1) how security constraints interact with other > security constraints, and See section 13.8.1 of the Servlet 4.0 spec. > (2) whether they can go in the conf/web.xml as > well as individual webapps' web.xml files. Yes they can. > As I said, I've got a query out to our web developers about *our* > webapp, but does Manager make any use of DELETE or OPTIONS? DELETE, no. OPTIONS, only in the sense it supports it but it doesn't depend on it being enabled so disabling OPTIONS won't break the manager app. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31
Thank you so much Mark! Moving to Tomcat 9.0.33 indeed solved the problem I was facing. Thanks, Amit -Original Message- From: Mark Thomas Sent: Tuesday, March 17, 2020 1:06 PM To: users@tomcat.apache.org Subject: Re: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 On 17/03/2020 17:56, Amit Pande wrote: > Using Tomcat 9.0.31. > > When using large JSON payload (little less than 2 MB) for POST requests, randomly (all random failures seen are on Windows and not on *ix), we are seeing: > > JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz ["str"]) - JSON parse error: Unexpected end-of-input in VALUE_STRING; nested exception is com.fasterxml.jackson.databind.JsonMappingException: Unexpected end-of-input in VALUE_STRING at [Source: (PushbackInputStream); line: 1, column: 17] (through reference chain: com.abc.xyz["str"])at > > For smaller payloads, no issues are observed. > > Will this also be addressed by upgrading to 9.0.32/33? Maybe. The only way for you to be sure that the issue you describe is the same as Bug 64202 is for you to download 9.0.33 and test it in your test environment. Mark > > Thanks, > Amit > > -Original Message- > From: Manuel Dominguez Sarmiento > Sent: Tuesday, March 17, 2020 10:52 AM > To: Tomcat Users List ; Christopher Schultz > Subject: [EXTERNAL] Re: Uploads breaking post upgrade to 9.0.31 > > Great, I just saw that :-) > > On 17/03/2020 11:24, Christopher Schultz wrote: > Manuel. > > On 3/17/20 09:25, Manuel Dominguez Sarmiento wrote: Hi Mark, when is 9.0.32 expected to be released? We've seen this issue reported by several users, even if we haven't run into this particular case directly (yet) > 9.0.33 was announced about 20 minutes ago :) > > -chris > On 17/03/2020 09:51, Mark Thomas wrote: > https://bz.apache.org/bugzilla/show_bug.cgi?id=64202 > > Mark > > On 17/03/2020 11:46, Srijith Kochunni wrote: >> Hi All, >> >> >> >> This is to seek help on a strange issue that we are observing. >> We recently did a minor upgrade of Tomcat from 9.0.30 to 9.0.31, >> in our application, in order to address vulnerability in AJP >> connector. Ever since then we have started seeing upload failures >> with our upload servlet when processing large files. >> Small files do get uploaded, but when we upload large files and >> we do Multipart file upload, we are randomly and yet consistently >> seeing that we get the following exception. >> >> >> >> [org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: >> >> > Processing of multipart/form-data request failed. Stream ended >> unexpectedly >> >> at >> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpl >> oa >> d > Base.java:351) >> >> >> > >> Caused by: >> org.apache.commons.fileupload.MultipartStream$MalformedStreamExce >> pt >> i > on: >> > Stream ended unexpectedly >> at >> org.apache.commons.fileupload.MultipartStream$ItemInputStream.mak >> eA >> v > ailable(MultipartStream.java:1005) >> >> >> > at >> org.apache.commons.fileupload.MultipartStream$ItemInputStream.rea >> d( >> M > ultipartStream.java:903) >> >> >> > at java.io.InputStream.read(InputStream.java:101) >> at >> org.apache.commons.fileupload.util.Streams.copy(Streams.java:100) >> >> >> > at >> org.apache.commons.fileupload.util.Streams.copy(Streams.java:70) >> >> >> > at >> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUpl >> oa >> d > Base.java:347) >> >> >> >> >> > It appears that the connection is getting reset in the >> middle of the upload, but the client is very much up and we get >> PR_CONNECT_RESET_ERROR on the browser. >> >> >> >> My code on the server side is as simple as >> >> >> >> DiskFileItemFactory factory = new DiskFileItemFactory(); >> >> ServletFileUpload fileUpload = new ServletFileUpload(factory); >> >> >> >> List fileItems = fileUpload.parseRequest(originalRequest); >> >> >> >> >> >> We would like to know if anyone else has observed this and if >> there is any way we can debug this further. When I try to attach >> and debug, the upload however seems to go through fine and is >> only failing when I am not attached to the process. Any help / >> suggestions would be much appreciated. >> >> >> >> >> >> >> >> Thanks, >> >> >> >> Srijith. >> >> >> >> >> >> >
Re: Security audit raises questions (Tomcat 7.0.93)
On 17/03/2020 23:30, Martynas Jusevičius wrote: > Tomcat does not allow DELETE by default? I’m using 8.0.x with Jersey and I > don’t think I used any config to enable it. By default, HttpServlet (which pretty much every servlet extends) returns a 405 for a DELETE. The Servlets that Tomcat implements either leave that unchanged or require explicit configuration (DefaultServlet, WebdavServlet) to allow the DELETE method. If an application (or a library / framework) wants to implement DELETE then they are free to do so and Tomcat won't stop them. The assumption is that the developers of that library / framework will either secure access appropriately and/or explain to their users how to do so. The only method Tomcat blocks by default is TRACE. Not because TRACE is insecure, it isn't, but because at least one browser implementation was (may be still is) dumb enough to process the response as HTML rather than plain text. And that creates security issues. Mark > > On Tue, 17 Mar 2020 at 23.50, Mark Thomas wrote: > >> On March 17, 2020 10:31:06 PM UTC, "James H. H. Lampert" < >> jam...@touchtonecorp.com> wrote: >>> >>> On 3/17/20 3:18 PM, Martynas Jusevičius wrote: why should DELETE or OPTIONS not be enabled? They are standard HTTP >>> methods. >>> >>> True, but (quoting the audit report) . . . [DELETE] may allow a remote attacker to delete arbitrary files >>> . . . . >> >> There is a big difference between supporting a method (recognising it is a >> known HTTP method) and allowing it. >> >> Tomcat does not allow DELETE by default. Your app might but one assumes if >> it does the developers know what they were doing and secured it >> appropriately... >> >> Tomcat takes the view that OPTIONS should list all supported methods, not >> just methods allowed, for a given resource. >> >>> and (again quoting the report) Web servers that respond to the OPTIONS HTTP method expose what other methods are supported by the web server, allowing attackers to narrow and intensify their efforts. >> >> That is a security by obscurity argument. The Tomcat devs have never given >> much ,(any?) weight to arguments made on that basis. >> >> The XXS might be valid. I assume the tool provided a sample URL you could >> use to validate the finding. That should point you in the right direction >> but feel free to ask here if more help is required. >> >> Mark >> >> >>> -- >>> JHHL >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [External] Re: Starting up Tomcat 8
On 17.03.2020 21:43, Maxfield, Rebecca A wrote: Ah, some problems are arising because, I suppose, the startup process wants to create or touch something in ../logs and that's now all the way over in /var/lib/tomcat8. How do I move on from here? Try (as root) : service tomcat8 start (or restart or stop ..) As mentioned before, the Debian package is assembled in such a way that it will function in the same way as other "services" in the Debian environment, log in the same general place etc.. The above command in fact runs the shell script at /etc/init.d/tomcat8. This script sets a number of variables before calling tomcat's startup.sh, changes to the approriate directory etc.. If you want a tomcat8 which is installed in a single directory, and which reacts in the "canonical" way as explained on the tomcat website, then you would have to de-install the Debian tomcat8 package, and install tomcat8 as per the tomcat website. But that's probably, in your case, more work than necessary. You just want to run some tomcat applications (webapps), right ? On 3/17/20, 4:40 PM, "Maxfield, Rebecca A" wrote: I see it now in /usr/share/tomcat8/bin, thank you! Can I just run startup.sh from there or is that not right? On 3/17/20, 4:37 PM, "André Warnier (tomcat/perl)" wrote: On 17.03.2020 21:18, Maxfield, Rebecca A wrote: > Both are Linux. The new is Debian, the old ?? On a Debian Linux system, tomcat 8 installed via the standard Debian package manager results in some files appearing in the following directories (and maybe others) - /etc/tomcat8 - /usr/share/tomcat8 - /var/lib/tomcat8 - /var/log/tomcat8 - .. ? Some of the entries in these directories are links pointing somewhere else. It is sometimes a bit difficult to follow. But it works, and it allows tomcat to be managed using the Debian usual commands for starting/stopping services, install updates etc.. Use this command to see a full list of the directories/files used : dpkg --listfiles tomcat8 (Note : this gives a list of directories/files initially reated or installed by the standard Debian tomcat8 package. But it does not include anything created/installed later on maybe to "customise" tomcat8 on that machine). > > On 3/17/20, 4:03 PM, "André Warnier (tomcat/perl)" wrote: > > On 17.03.2020 19:52, Maxfield, Rebecca A wrote: > > Hello, > > > > I manage a project that currently runs on Tomcat 7 but is migrating to a new server where Tomcat 8 was installed by the server admin. When I navigate to the /var/lib/tomcat8 folder, I don’t see a ./bin folder or any startup.sh or similar. Is this something that has changed from Tomcat 7 to Tomcat 8, or does this imply that it was not installed completely/correctly? > > > What is the platform (OS) of the new server ? (and the old one) > Maybe it was installed using a package provided by the platform, in (eminently variable) > other directories. > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > › This email was sent from outside of Providence College > › Do not click any suspicious links or open any attachments that you are not expecting > › Never send any sensitive or financial information (Including passwords, social security numbers, credit card numbers, and gift cards) via email > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe,
Re: Security audit raises questions (Tomcat 7.0.93)
On 18.03.20 01:04, James H. H. Lampert wrote: > On 3/17/20 3:50 PM, Mark Thomas wrote: >> The XXS might be valid. I assume the tool provided a sample URL you >> could use to validate the finding. That should point you in the right >> direction but feel free to ask here if more help is required. > Near as I can tell, it did but it didn't provide a sample URL. > > Note that *all* I have is a PDF of the report, and I think the URL may > have gotten mangled by spanning a page-break. I've posted a screenshot > (with identifying information redacted) of what I'm looking at in the > report: > > https://www.flickr.com/gp/64159238@N03/02i78o > This issue, according to that screenshot, seems to be on an error.jsp. The only error.jsp that I could find in Tomcat 7.0.93 and 7.0.100 is in webapps/examples/jsp/security/protected/error.jsp, i.e. under /webapps/examples Are you sure that this is for tomcat, not for your own application? Looking at tomcat's jsp, it's as simple as it can be, takes no external input, and doesn't generate markup as the one you've posted. But just in case: That examples webapp probably shouldn't be deployed on production servers anyway (seeing it there, IMHO it'd be a good idea to not package it in this way in the first place, but that's a different story) Cheers, Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2
Grande Brian, congrats! Sorry, I've just read your message, a bit late to the party: time ago I had cooked a tomcat9 container + log4j2 with a sample spring-boot app deployed. You can have a look here [1] Cheers, Luis [1] https://db-blog.web.cern.ch/blog/luis-rodriguez-fernandez/2019-03-keeping-your-logs-clean-apache-tomcat-9-log4j2-and-spring-boot El mié., 18 mar. 2020 a las 8:44, Brian Burch () escribió: > On 18/3/20 5:18 pm, Brian Burch wrote: > > > > Could resist tinkering a bit more, but I'll be in trouble because I'm > late for dinner!! > > Success! I have just created the catalina.log file formatted according > to my own log4j2.xml. > > Yes, it was my stupid mistake, but I'll write tomorrow about what it did > to make it work. > > Thanks for listening and advising. It really helped a lot and I wouldn't > have cracked it on my own. > > Brian > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better." - Samuel Beckett
Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2
On 18/3/20 5:18 pm, Brian Burch wrote: Could resist tinkering a bit more, but I'll be in trouble because I'm late for dinner!! Success! I have just created the catalina.log file formatted according to my own log4j2.xml. Yes, it was my stupid mistake, but I'll write tomorrow about what it did to make it work. Thanks for listening and advising. It really helped a lot and I wouldn't have cracked it on my own. Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Fwd: Advice please for Tomcat 8.5.53-dev with log4j2
On 18/3/20 2:57 pm, Brian Burch wrote:
I have done quite a lot of experiments, but I will stick to the case
which appears to have produced the most encouraging(!) results.
I stumbled across
https://logging.apache.org/log4j/2.x/log4j-appserver/index.html.
This short page has significant overlap with your suggestions, but there
are differences too. I'll compare both before I say much more.
Your setenv puts log4j-api-2.13.1.jar on the classpath, but this file
does not exist in my log4j2 binary download.
Following their advice, I first tried replacing it with
log4j-appserver-2.13.1.jar, but startup failed with ClassNotFoundException.
Then I added (not replaced) log4j-1.2-api-2.13.1.jar, which seemed to be
a good guess. That failed as follows:
Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: org.apache.juli.logging.LogConfigurationException:
java.lang.reflect.InvocationTargetException
at
org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:136)
at
org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:153)
at org.apache.juli.logging.LogFactory.getLog(LogFactory.java:208)
at
org.apache.catalina.startup.Bootstrap.(Bootstrap.java:51)
Caused by: java.lang.reflect.InvocationTargetException
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.apache.juli.logging.LogFactory.getInstance(LogFactory.java:134)
... 3 more
Caused by: java.lang.NoClassDefFoundError:
org/apache/logging/log4j/LogManager
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:468)
at java.net.URLClassLoader.access$100(URLClassLoader.java:74)
at java.net.URLClassLoader$1.run(URLClassLoader.java:369)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at
org.apache.logging.log4j.appserver.tomcat.TomcatLogger.(TomcatLogger.java:67)
... 8 more
However, I suspected my "current best effort" had disabled the internal
tomcat logging (juli) but failed to enable log4j2. The message I quoted
from catalina.out looked suspiciously like it had been handled by the
jvm Logger, which is consistent with your suggestion
> I tried building log4j2 from source and gave up. It is a bit of a
nuisance that my development system uses both OpenJDK 8 and 11 because I
keep forgetting which is required by my different projects. The log4j2
toolchains requirement for java 9 was just too much to contemplate!
Clearly, adding log4j-1.2-api-2.13.1.jar did something significant, but
I guess the jar is incompatible in some manner?
I recall the log4j2 pom.xml has a java.target of 1.7, as well as its
toolchain requirement for java 9. I'm doing my very best to build and
run tomcat under java 8. Is this relevant, or just a red herring?
I downloaded the apache-log4j-2.13.1 binaries, so I will deploy those
jars in my tests.
I needed to make some minor tweaks to your setenv.bat before I had a
syntax-free setenv.sh. Of course, I also replaced your ${CATALINA_BASE}
with ${CATALINA_HOME} because that's where I'm currently putting the
logging jars.
That bootstrap directory also has a copy of tomcat-juli from my java 8
build from 5.8.53-dev source:-
-rw-r--r-- 1 tomcat8 tomcat8 51224 Mar 9 17:24 tomcat-juli.jar
I also noted from the web advice above that log4j2 looks for it's
configuration file under the name log4j2-tomcat.xml, not log4j2.xml. I'm
not keen on the advice to deploy the jars to new tomcat directories
called catalina.home/log4j2/lib and ./log4j2/conf, so I favour your
suggestion of using catalina.home/bin for my first tests.
Oh yes...
It didn't make any difference whether I called my configuration file
conf/log4j2.xml or conf/log4j2-tomcat.xml.
I don't think it should matter that the default conf/logging.properties
does not exist... wdyt?
I really appreciate your thoughtful advice. It would be useful for me to
pare the advice down to its essentials and then update the tomcat 8 wiki
advice.
So, to summarise, I've eliminated a lot of possible solutions and
changed the failure
