RE: Re: Embedded Tomcat common classloader

[Terence M. Bandoian]

n]
> > java -cp ‘mylib/*’ ClassName
> >
> > do not use shell expansion, since a Linux/UNIX shell is put off by 
the colon or apostrophes.

> >
> > - Chuck
> >
> >
> > -
> > 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
>
>
--
/Terence M. Bandoian
Software Design and Development
http://www.tmbsw.com/
tere...@tmbsw.com
512.487.5887/

Re: Tomcat 9 memory leak message

[Terence M. Bandoian]

A long time ago (Tomcat 7), I would see a Tomcat memory leak detection 
error on shutdown if the JDBC driver was located in WEB-INF/lib but not 
if it was in the Tomcat lib directory. Explicitly de-registering the 
driver with a ServletContextListener on shutdown eliminated the error. 
I'm not sure if that's still necessary or if it applies in your case.


-Terence Bandoian

On 6/2/2024 1:56 AM, Christopher Schultz wrote:

Jenny,

(Apologies for top-posting)

“Safely ignored” can mean many things. You are only in danger of running out of 
heap space. So if you aren’t worried about that, feel free to ignore the error 
message.

If it were my system, I would want to ensure a clean unload of the driver when 
the application shuts down.

But I don’t think it will harm anything besides your memory usage.

-chris


On Jun 1, 2024, at 00:18, Ying Jin  wrote:

Chris,

Thanks for your reply!

We already removed the ojdbc8.jar file from the application's Web-inf/lib
folder as suggested in the following post, however, we still got the
warning messages below after the application is deployed to the Tomcat 9
server.

https://stackoverflow.com/questions/6981564/why-must-the-jdbc-driver-be-put-in-tomcat-home-lib-folder

WARNING: The web application [Our Web Application Name] appears to have
started a thread named [InterruptTimer] but has failed to stop it. This is
very likely to create a memory leak. Stack trace of thread:

WARNING: The web application [Our Web Application Name] appears to have
started a thread named [oracle.jdbc.diagnostics.Diagnostic.CLOCK] but has
failed to stop it. This is very likely to create a memory leak. Stack trace
of thread:

I also read some posts saying these warning messages can be safely ignored
if the Tomcat version is greater than 7.0. I'm not sure if this is correct
or not.

Please advise,

Many thanks!
Jenny


On Fri, May 31, 2024 at 3:50 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

Jenny,


On 5/31/24 14:52, Ying Jin wrote:
We removed the ojdbc8 driver jar from web-inf/lib from the web
application and kept the ojdbc8 jar file in the Tomcat/lib folder, but
we still can see the following memory link warning message whenever we
redeploy the web application. We use the Tomcat 9 server in the Linux
environment.

This list strips attachments. Can you re-post with text-only?


The other warning message is about the "validateFile Problem with jar
file /tomcat/lib/jolokia.jar. My question is if we can safely ignore
these warning messages or not.

It would be great if you can shed some light on this issue.

If the message is something like "driver cannot be unloaded" then check
Tomcat with a debugger or even something like JVisualVM to see how many
WebappClassLoaders you have in memory.

If the driver causes the web application ClassLoader to be "pinned" in
memory, then it will never be removed and all those classes will
continue to use-up heap space until you restart the JVM. This gets worse
every time you reload your application without restarting the JVM. The
Manager application web UI can help you diagnose these a little.

The validation problem with the Jolokia JAR file will depend upon
exactly what it says. I would first get a replacement copy of the
Jolokia JAR file before bothering to try to diagnose it any further.

-chris

-
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: Database Connection Requests Initiated but Not Sent on the Wire (Some, Not All)

[Terence M. Bandoian]

On 5/31/2024 11:44 AM, Mark Thomas wrote:

On 31/05/2024 16:09, Eric Robinson wrote:

The results are looking great so far.


Excellent.


Here's what we know:

Before the patch, we had 2 load-balanced tomcats in production for 
this customer. Due to the driver search bottleneck, we were seeing 
hundreds of stuck threads during the slowdown periods. To work around 
this problem, we threw more tomcats at it. With 6 tomcats, the load 
was spread around enough to keep the bottleneck condition from 
manifesting badly, and users did not complain as much. We were still 
seeing dozens of stuck threads, but not hundreds.


After the patch, we went back to 2 tomcats.


I appreciate the show of faith! I think that is braver than I would 
have been but it does rather confirm both the problem and the fix.


During the same timeframe today, there have been 1 stuck thread on 
Tomcat A and 6 on Tomcat B.


That is great news.


If the numbers hold, this works out to roughly a 10,000% improvement.


Not bad for free support ;)

Seriously, I am glad that we seem to have tracked down the root cause 
and that you have a temporary fix that works until such time (probably 
the July releases) that we can figure out how we want to address 
caching of "not found" classes.


Cheers,

Mark


Kudos!

Would this mean that a "not found" class would be forever "not found" 
until a restart? How does Tomcat handle jars or classes added or removed 
while it's running now? Could a class be removed from the "not found" 
cache if a change was detected? Would it be worth maintaining a list of 
all available classes?


Really well done!

-Terence

Re: [OT] Tomcat not syncing existing sessions on restart

[Terence M. Bandoian]

I would suggest focusing on Docker networking rather than Tomcat. My 
guess is that how that works will inform your Tomcat configuration. You 
might also try first getting it to work with two Docker instances on a 
single machine.


-Terence Bandoian

On 3/1/2024 11:59 AM, Manak Bisht wrote:

I am fairly certain now that the docker container is the problem. I am
unable to replicate the issue without it. Using the hostname/IP address of
the host (tomcat/ip) for the receiver always causes the following problem,
01-Mar-2024 22:30:32.315 INFO [main]
org.apache.catalina.tribes.transport.ReceiverBase.bind Unable to bind
server socket to:tomcat/ip:4000 throwing error.
01-Mar-2024 22:30:32.315 SEVERE [main]
org.apache.catalina.tribes.transport.nio.NioReceiver.start Unable to start
cluster receiver
  java.net.BindException: Cannot assign requested address
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at
org.apache.catalina.tribes.transport.ReceiverBase.bind(ReceiverBase.java:184)
at
org.apache.catalina.tribes.transport.nio.NioReceiver.bind(NioReceiver.java:125)
at
org.apache.catalina.tribes.transport.nio.NioReceiver.start(NioReceiver.java:89)
at
org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:150)
at
org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:102)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor.start(StaticMembershipInterceptor.java:108)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.start(TcpPingInterceptor.java:65)
at
org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:155)
at
org.apache.catalina.tribes.group.GroupChannel.start(GroupChannel.java:421)
at
org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal(SimpleTcpCluster.java:544)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:902)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:439)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:760)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.startup.Catalina.start(Catalina.java:625)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:351)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:485)

Either address binding does not work for any address inside the container
or just binding to the address of the host machine does not work. I am
leaning towards the latter because the * *element has never
exhibited this issue. Here's what I have already tried/checked,

- The receiver/address port of the container is mapped to the same port
on the host
- The IP of the host is reachable via ping and telnet from the container.
- Running the following code from inside the container always works
java.net.InetAddress bind = java.net.InetAddress.getByName("tomcat");
System.out.println(bind); // Output: tomcat/ip

I have read a lot of resources and tried a variety of solutions to no
avail. Literature covering session replication with containerisation is
also sparse. If someone has tried this before or has any ideas, please let
me know, I would greatly appreciate it.

Sincerely,
Manak Bisht


On Mon, Feb 12, 2024 at 9:07 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Manak,

On 2/12/24 10:33, Manak Bisht wrote:

Chris,

On Mon, 12 Feb 2024, 20:52 Christopher Schultz, <
ch...@christopherschultz.net> wrote:


I wouldn't refuse to configure, since anyone using
0.0.0.0 with /separate/ hosts wouldn't experience this problem.


I am using separate hosts (two docker containers on two different

machines)

in my main deployment. I just reproduced the 

Re: How does the user principal get set on the servlet container session?

[Terence M. Bandoian]

What should happen if 
session.getAttribute("javax.security.auth.subject") returns a non-null 
value?


-Terence Bandoian

On 1/30/2024 5:15 PM, Ryan Esch wrote:

>From what I understand, the container knows if a user is authenticated by 
using the session id passed to it and then looking up the user principal. If this 
is non-null, the user is authenticated. I am using web.xml with security 
constraints and UsersRoleLoginModule defined in jaas.conf which is working fine. I 
want to add an additional method of login.
How do I set the principal on the session in my custom login module? I have 
tried a number of things, including:
HttpSession session = request.getSession();

// Retrieve or create the Subject
Subject subject = (Subject) session.getAttribute("javax.security.auth.subject");
if (subject == null) {
 subject = new Subject();
 session.setAttribute("javax.security.auth.subject", subject);
}
subject.getPrincipals().size());

Principal customPrincipal = new CustomPrincipal("Random Username");
subject.getPrincipals().add(customPrincipal);All my calls to 
request.getUserPrincipal() are null so of course my custom login 
fails.Alternatively/additionally, can I configure the container to also check 
for an access token for authentication?
Thank you for any input or advice. I'd be happy to share additional details.Ryan

Re: webdav and libreoffice

[Terence M. Bandoian]

Have you tried with Tomcat 9.0.31 and Ubuntu 22.04?  Or Tomcat 9.0.31 
and CentOS 9?


-Terence

On 11/28/2023 9:00 PM, Jean-Max Reymond wrote:
Libreoffice cannot write the document with tomcat 9.0.58  and tomcat 
9.0.68, but it is ok with tomcat 9.0.31

debug mode shows a lot of PROPFIND but no crash.

Le 29/11/2023 à 00:53, Terence M. Bandoian a écrit :

What is the error?  Log?  Stack trace?

-Terence Bandoian

On 11/28/2023 4:27 PM, Jean-Max Reymond wrote:

Hi,
I have an application and a webdav servlet with tomcat.
I am using libreoffice to edit and save files.
the command is:
/usr/lib/libreoffice/program/soffice.bin 
ms-excel:ofe|u|https://cloud.example.com/WebDav/NESTOR/GERARD/Documents.xls 
--splash-pipe=5


With tomcat 9.0.31 and Ubuntu 20.04, all is OK, editing and saving
With tomcat 9.0.58 and Ubuntu 22.04, failed to save the document 
with message : Error saving document Documents.xls
Unable to create object in directory 
https://cloud.example.com/WebDav/NESTOR/GERARD/Documents.xls

With tomcat 9.0.69 and centos 9, same as tomcat 9.0.58

For all the tomcat versions, it is OK with MS Office (Word, Excel, ...)
What happens between  tomcat 9.0.31 and tomcat9.0.58 ?
Thanks for your tips,

-
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: webdav and libreoffice

[Terence M. Bandoian]

What is the error?  Log?  Stack trace?

-Terence Bandoian

On 11/28/2023 4:27 PM, Jean-Max Reymond wrote:

Hi,
I have an application and a webdav servlet with tomcat.
I am using libreoffice to edit and save files.
the command is:
/usr/lib/libreoffice/program/soffice.bin 
ms-excel:ofe|u|https://cloud.example.com/WebDav/NESTOR/GERARD/Documents.xls 
--splash-pipe=5


With tomcat 9.0.31 and Ubuntu 20.04, all is OK, editing and saving
With tomcat 9.0.58 and Ubuntu 22.04, failed to save the document with 
message : Error saving document Documents.xls
Unable to create object in directory 
https://cloud.example.com/WebDav/NESTOR/GERARD/Documents.xls

With tomcat 9.0.69 and centos 9, same as tomcat 9.0.58

For all the tomcat versions, it is OK with MS Office (Word, Excel, ...)
What happens between  tomcat 9.0.31 and tomcat9.0.58 ?
Thanks for your tips,

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: page extends not working???

[Terence M. Bandoian]

On 9/11/2023 9:05 AM, Aryeh Friedman wrote:

On Mon, Sep 11, 2023 at 9:47 AM Christopher Schultz
  wrote:

Aryeh,

On 9/9/23 19:36, Aryeh Friedman wrote:

On Sat, Sep 9, 2023 at 1:23 PM Mark Thomas  wrote:

On 09/09/2023 11:52, Aryeh Friedman wrote:

Every other jsp in my webapp (and other webapps on the same tomcat
instance [9.0.75]) works and I am using a the default container but as
curl/catalina.out show BasePage is *NEVER* being called (either the
_jspService() or the getX()):

How have you configured your JSP(s) to use this alternative base class?

sudo cat /usr/local/apache-tomcat-9.0/webapps/tlaitc-dashboard-1a1/index.jsp

<%@page extends="dashboard.web.pages.BasePage"%>
hi x is ${x}

Output shown in log (sorry for not including the JSP the first time)
but to make it easier to find the output is "hi x is " when it should
be "hi x is 123234"... as you notice there are zero errors/warning in
catalina but there is none of the println's also... so the only thing
I can surmise is BasePage is never being called <%@page
extends="dashboard.web.pages.BasePage"%> somehow failed but I have
verified that correct spelling several times and also verified any
syntextual errors [including the contents of the string literal] will
show up in catalina.out (i.e. wrong class name is logged as an error)

Your _jspService method in your base class will never be called, because
it is overridden by the auto-generated class for your JSP, which does
not call super._jspService.

I do not believe that this:

Hi X is ${x}

...will result in this.getX() being called from the JSP. References in
EL ${...} expressions will be resolved against the PageContext (and
other wider contexts), not against the JSP class currently executing.

If you want to call this.getX() then you will need to do this:

Hi X is <% getX() %>

I wouldn't bother messing-around with class hierarchies in JSP. It
usually doesn't get you much but almost always requires you to bind
yourself very closely with the specific implementation of the JSP engine.

It would be far better to use typical MVC-style development where a
servlet (or similar) handles the real work of the request, possibly
including writing a value of "x" to the request attributes. Then forward
your request to your JSP to produce the response content. This will be
much more straightforward and you will have fewer problems like this,
where expected behavior is confused by all the magic that JSP provides.

Thanks but I have a very specific use case which the following working
example below should make more clear:


<%@page import="dashboard.web.page.Page"%>
<%
 // THIS WOULD NOT BE NEEDED if <%@page extends="..."%> worked
 //
 // for now we don't need to keep the page object just
 // the setAttributes in our ctx
 new Page(pageContext);
%>



 <%@include file="/widgets/scripts/scripts.jsp"%>


  



and the Page class:

package dashboard.web.page;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.jsp.PageContext;

import org.petitecloud.util.PetiteCloudNullException;

// making this extend the right subclass plus working page
extends="" would mean zero in-line Java
// Copyright (C) 2023 TLAITC and contributors
public class Page
{
 public Page(PageContext ctx)
 {
 _dbc_construction(ctx);

 this.ctx=ctx;

 HttpServletRequest req=(HttpServletRequest) ctx.getRequest();
 String[] parts=req.getRequestURI().split("/");
 int split=2;

 if(parts[0].equals("http:"))
 split+=2;

 name="";
 for(int i=split;i
<%@page extends="dashboard.web.page.Page"%>



 <%@include file="/widgets/scripts/scripts.jsp"%>


  



Side note I am currently adding user detection to the above page class
to that it can auto-enforce ACL's



It's been a while since I've looked at JSP but, from what I've read, the 
JavaServer Pages Specification recommends using taglib to introduce new 
implicit objects and warns against using extends.


Also, wouldn't Page have to extend a specific class for this to work?  
It seems like that was done in one of your earlier posts. Would that 
unnecessarily tie your application to Tomcat?


If what you're worried about is inline Java, could that preamble be 
provided using an include directive?  That might be a simple way to 
clean up the code.  From the code you've provided, that might amount to 
a single call to a static method defined, for example, in Page.


-Terence Bandoian

Re: Forwarding request to a different servlet

[Terence M. Bandoian]

Hi, Andy-

I'd suggest looking at:
ServletContext.getContext

and comparing:
ServletContext.getRequestDispatcher with
ServletRequest.getRequestDispatcher

Hope that helps.

-Terence Bandoian

On 8/11/2023 2:52 AM, Andy Pont wrote:

Hello!

We have a commercial application that runs under Tomcat 8.5.65 (on 
Windows Server 2019).  In the tomcat/webapps directory there are the 
following three directories (names changed):


backend
frontend
ROOT

The “frontend” directory contains the UI for the commercial 
application and is, as far as I can tell, all just HTML, JavaScript, 
etc.  The “backend” directory contains the parts of the system that do 
the bulk of the work and appear to be mainly .jsp files.


Amongst other things, the “backend” handles a URL 
https:///backend/rest/abc/xx where “xx” represents a 
number that tells it what to act upon.


I have started developing a new servlet which handles POST requests to 
the URL: https:///plugins/abc/xx. In some cases (based on 
a values in the request body), the servlet will process things itself 
and generate its own response.   For certain cases it just needs to 
forward the request on to corresponding “backend” URL and then pass 
the response back.


I assumed that .forward(request, response) on a RequestDispatcher 
would be what I needed to use.  I have tried every combination of 
getServletContext() and getRequestDispatcher() I can think of or have 
found on the internet but it always fails with an HTTP error 404.  
This is because the URL that it is being forwarded to always has a 
rogue “plugins” in it, i.e. 
https:///plugins/backend/rest/abc/xx.


I suspect the solution is simple but I am new to Tomcat and developing 
servlets and probably missing something obvious.  Any guidance would 
be much appreciated.


-Andy.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Can We Disable Chunked Encoding?

[Terence M. Bandoian]

On 7/24/2023 10:09 AM, Eric Robinson wrote:

My apologies. I wasn't aware that something else besides the subject line 
identifies a thread. I thought changing the subject line *IS* starting a new 
thread. Thanks for letting me know. For my own edification, what does the list 
look for in a message to identify the thread?


Check the message source for headers identifying the thread.

-Terence Bandoian


-Original Message-
From: Mark Thomas
Sent: Thursday, July 6, 2023 3:13 AM
To:users@tomcat.apache.org
Subject: Re: Can We Disable Chunked Encoding?

Please don't hijack threads by replying to a previous message and changing
the subject. Start a new thread by sending a new message to the list.

You also need to provide some version information.

Mark


On 06/07/2023 00:36, Eric Robinson wrote:

We've been seeing problems with failed requests where the response comes

back with duplicate chunked encoding headers:

[Response]

HTTP/1.1 200
Strict-Transport-Security: max-age=86400; includeSubDomains;
Cache-Control: no-cache,no-store
isAuthenticated: true
X-FRAME-OPTIONS: SAMEORIGIN
Transfer-Encoding: chunked  <
X-XSS-Protection: 1; mode=block
vary: accept-encoding
Content-Encoding: gzip
Content-Type: text/xml;charset=ISO-8859-1
Transfer-Encoding: chunked  << Duplicate
Date: Wed, 05 Jul 2023 17:22:11 GMT

This is a violation of RFC 7230, so our nginx proxy is dropping the request

and returning a 502 bad gateway error. I've spoken to F5 about this, and
there's no way to make nginx ignore this violation. Unfortunately, the app is a
canned product, and we don't have access to the code.

Is there a way to disable that behavior in Tomcat?

-Eric


Disclaimer : This email and any files transmitted with it are confidential and

intended solely for intended recipients. If you are not the named addressee
you should not disseminate, distribute, copy or alter this email. Any views or
opinions presented in this email are solely those of the author and might not
represent those of Physician Select Management. Warning: Although
Physician Select Management has taken reasonable precautions to ensure no
viruses are present in this email, the company cannot accept responsibility for
any loss or damage arising from the use of this email or attachments.

-
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

Disclaimer : This email and any files transmitted with it are confidential and 
intended solely for intended recipients. If you are not the named addressee you 
should not disseminate, distribute, copy or alter this email. Any views or 
opinions presented in this email are solely those of the author and might not 
represent those of Physician Select Management. Warning: Although Physician 
Select Management has taken reasonable precautions to ensure no viruses are 
present in this email, the company cannot accept responsibility for any loss or 
damage arising from the use of this email or attachments.

-
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: Best Practice to Upgrade Apache Tomcat from 9.0.56 to 9.0.74

[Terence M. Bandoian]

This might be helpful:

https://docs.oracle.com/en/java/javase/17/docs/specs/man/jar.html

-Terence Bandoian


On 5/17/2023 11:06 PM, Meltron Kendrick wrote:

I created a "jar" file using WinRAR -- but no go ---

Got the following error message...

"Error: Could not find or load main class
org.apache.catalina.util.ServerInfo"

Any ideas on HOW TO properly do this?




On Wed, May 17, 2023 at 9:58 PM Meltron Kendrick 
wrote:


I was able to DECOMPRESS the .jar file -- using 7-zip -- and edited the
org/apache/catalina/util/ServerInfo.properties file to the proper version
and date info...

Now I need to COMPRESS everything with the updated
org/apache/catalina/util/ServerInfo.properties file added back into the
.jar file...


On Wed, May 17, 2023 at 1:43 AM Meltron Kendrick <
meltronkendr...@gmail.com> wrote:


Thank you Chuck!

What is the best way to go about updating the 3 lines to accurately
reflect the proper version details?



On Tue, May 16, 2023 at 9:08 PM Chuck Caldarale  wrote:


On 2023-05-16, at 17:02, Meltron Kendrick 

wrote:

I am trying to get these fields to UPDATE properly...

ESPECIALLY THESE 3 ---
(but all of them would be nice)

Server version:  Secure Web Server
Server built: Jan 01 2000 00:00:00 UTC
Server number: 1.0.0.0

This information comes from this file inside lib/catalina.jar:
 org/apache/catalina/util/ServerInfo.properties

Whoever built your Tomcat distribution changed the contents of that file
when constructing the package. Using an unadulterated download from
tomcat.apache.org  results in something
similar to the following when running the version command:

Server version: Apache Tomcat/11.0.0-M6
Server built:   May 3 2023 17:28:15 UTC
Server number:  11.0.0.0
OS Name:Mac OS X
OS Version: 13.3.1
Architecture:   aarch64
JVM Version:18.0.1.1+2-6
JVM Vendor: Oracle Corporation

   - Chuck

--

==
Blessed Regards,

Meltron Kendrick
Sr. Systems Engineer
Linux * Windows * Cloud Computing * Security

LinkedIn: http://www.linkedin.com/in/meltronkendrick

Mobile: (512) 233-9176
Email: meltronkendr...@gmail.com


--
==
Blessed Regards,

Meltron Kendrick
Sr. Systems Engineer
Linux * Windows * Cloud Computing * Security

LinkedIn: http://www.linkedin.com/in/meltronkendrick

Mobile: (512) 233-9176
Email: meltronkendr...@gmail.com




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Java G1 GC creating less garbage and taking more time in mixed GC phase

[M Venkata Pratap M]

Hi ,
1. Thanks for the reply , attached screenshots for 9.0.62 heapdump. 
2. http2.Stream objects is taking around 28MB. Also InputBuffer was 
occupying more memory  around 235MB. was it normal. 
3. In our application we are receiving 800 json requests per second an 
average of 3KB data each request and will respond with in a second.
4. All the tomcat settings are defaults , Overall anything suspicious 
from the screenshots. 

Thanks & Regards,
Venkat.

-Original Message-
From: Mark Thomas  
Sent: 16 May 2023 12:44
To: users@tomcat.apache.org
Subject: Re: Java G1 GC creating less garbage and taking more time in mixed GC 
phase



On 16/05/2023 05:12, M Venkata Pratap M wrote:
> Hi,
> 
>1.  We are using Http2 , When compared to 9.0.38 tomcat version , 9.0.62 
> version is creating less garbage and taking  more time(2 to 5 seconds) in 
> garbage collection during mixed GC phase.
>2.  Are there any recommendation GC setting. Has any one observed these 
> kind of problem.

Time spent in GC is generally proportional to the size of the live objects on 
the heap. I'd suggest comparing heap dumps from 9.0.38 and
9.0.62 to see what is different.

Mark

-
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

Java G1 GC creating less garbage and taking more time in mixed GC phase

[M Venkata Pratap M]

Hi,

  1.  We are using Http2 , When compared to 9.0.38 tomcat version , 9.0.62 
version is creating less garbage and taking  more time(2 to 5 seconds) in 
garbage collection during mixed GC phase.
  2.  Are there any recommendation GC setting. Has any one observed these kind 
of problem.
Thanks & Regards,
Venkat.

Re: ClassNotFound after upgrade to tomcat 10

[Terence M. Bandoian]

On 4/17/2023 6:13 PM, Kevin Huntly wrote:

Thank you, all set. I guess I wasn't googling the right things lol, either
that or I'm getting a little too used to asking on the list =(


Yes.

-Terence Bandoian


On Mon, Apr 17, 2023 at 7:03 PM Torsten Krah  wrote:


The whole thing is also well answered there btw:


https://stackoverflow.com/questions/4928271/how-to-install-jstl-the-absolute-uri-http-java-sun-com-jstl-core-cannot-be-r#4928309

Kevin Huntly  schrieb am Di., 18. Apr. 2023, 00:52:


I am now seeing this:

17-Apr-2023 18:50:44.450 SEVERE [catalina-exec-1]
org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service()

for

servlet [jsp] threw exception
 org.apache.jasper.JasperException:
/com.cws.esolutions.web.login/jsp/html/en/Login.jsp (line: [1], column:
[1]) Unable to find taglib [c] for URI: [jakarta.tags.core]

After updating the taglib imports on my jsp files


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 17, 2023 at 6:47 PM Torsten Krah  wrote:


And update your taglib definitions, see here:

https://jakarta.ee/specifications/tags/3.0/

The old ones are deprecated/ removed:

Quote:

Rename java.sun.com taglib URIs to new jakarta.tags.* URNs.



Kevin Huntly  schrieb am Di., 18. Apr. 2023,

00:34:

Now i'm getting these:

17-Apr-2023 18:32:03.236 INFO [main]
org.apache.catalina.core.ApplicationContext.log No Spring
WebApplicationInitializer types detected on classpath
17-Apr-2023 18:32:04.904 INFO [main]
org.apache.catalina.core.ApplicationContext.log Initializing Spring
DispatcherServlet 'eSolutions'
17-Apr-2023 18:32:16.844 SEVERE [catalina-exec-1]
org.apache.catalina.core.StandardWrapperValve.invoke

Servlet.service()

for

servlet [eSolutions] in context with path [/esolutions] threw

exception

[Handler processing failed: java.lang.NoClassDefFoundError:
jakarta/servlet/jsp/jstl/core/Config] with root cause
 java.lang.ClassNotFoundException:
jakarta.servlet.jsp.jstl.core.Config

17-Apr-2023 18:32:16.986 SEVERE [catalina-exec-1]
org.apache.catalina.core.ApplicationDispatcher.invoke

Servlet.service()

for

servlet [jsp] threw exception
 org.apache.jasper.JasperException:
/theme/cws/html/en/jsp/errHandler.jsp (line: [1], column: [1]) The

absolute

uri: [http://java.sun.com/jsp/jstl/core] cannot be resolved in

either

web.xml or the jar files deployed with this application

I removed the apache taglibs dependency, clearly that was a mistake.


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 17, 2023 at 6:26 PM Torsten Krah 

wrote:

You should only use https://jakarta.ee/specifications/tags/3.0/

and

not

the
old 1.2.5 one, remove that old one.
Why do you have both included?

Kevin Huntly  schrieb am Di., 18. Apr. 2023,

00:19:

6.0.0

1.2.5

3.0.0

3.1.1


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Mon, Apr 17, 2023 at 6:17 PM Torsten Krah 

wrote:

All the api ones have to be provided, not compile scope imho.

Tomcat

does

provide them, don't package them in your war file and double

check

the

versions from the guide, there is still a class referencing the

old

API

and

is causing the exception.

You missed to add the versions you used, add them here please,

the

information you provided is lacking those crucial detail.

Kevin Huntly  schrieb am Di., 18. Apr.

2023,

00:12:

Thank you for that... I have the right (I think) dependencies

in

my

pom:



org.apache.taglibs

taglibs-standard-impl

${taglibs.version}

jar

compile





jakarta.servlet.jsp.jstl

jakarta.servlet.jsp.jstl-api

${jstl.version}

jar

compile





jakarta.servlet.jsp

jakarta.servlet.jsp-api

${jsp-api.version}

jar

compile





jakarta.servlet

jakarta.servlet-api

${jakarta.servlet.version}

jar

provided




I just want to use the jstl tag libraries =(


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE

Apache Tomcat 10.0.26 Shortcut issue in our environment - Need Help

[P M, SRIHARIKUMAR (Consultant)]

Hi Team,

While validating source for Apache Tomcat 10.0.26, The shortcut is throwing 
error while launching. Please find the results below

Tomcat Version : 10.0.26

Operating system : Windows 10

Dependency : JAVA SDK 11 is installed.

Error : " The item referred to by this shortcut cannot be accessed. You may not 
have appropriate Permission".

Method tried but still could not make shortcut work:


  1.  Searched in Google and tried removing shortcut and created manually.
  2.  Rebooted the system and checked.
  3.  Started the Tomcat Service Manually and checked.
  4.  Provided Permission to the Shortcut pointing exe and tried.
  5.  Tried more than 5 Machines to make sure if its due to any machine related 
issue.


  1.  Error while launching Configure Tomcat Shortcut.


[cid:image003.png@01D967D6.F9D4DEC0]



  1.  Error while launching Monitor Tomcat Shortcut.


[cid:image005.png@01D967D6.F9D4DEC0]



  1.  Error while launching Tomcat Manager Shortcut.


[cid:image002.png@01D961AE.E6EFCFA0]


Thanks & Regards
Sriharikumar PM

Re: HTTP Error 414. The request URL is too long.

[Terence M. Bandoian]

On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing 
maxHttpHeaderSize as suggested on Google.  It worked for him for a while, but 
he encountered the same error again later on.
Our developers got involved and later discovered that our app was trying to 
display all his favourites and the customer somehow managed to accumulate a 
huge list of favourites. So, a hotfix was created to limit the size of the 
favourites that get displayed on to the browser.
I hope that helps you sort it out with the application to find what huge data 
is being push onto the url and limit it.
-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status code is 
originating, it isn't Tomcat. It must be in the application or in a component 
before Tomcat.

Mark




SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1
e=1=


   
  LSF
  01092390
  02
  
  test_promo_freeProduct
  DROP
  
  
  01092391
  WEB001232
  O
   
   
  
 39012621
 1.0
 BAG
  
   

 

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat 
access log if you can get a request that far.


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Database related performance degradation after upgrading from Tomcat 9.0.33 to Tomcat 9.0.69

[Terence M. Bandoian]

On 2/21/2023 10:58 PM, Konstantin Kolinko wrote:

ср, 22 февр. 2023 г. в 01:31, Artur Tomusiak - Hannon Hill
:

After upgrading from Tomcat 9.0.33 to Tomcat 9.0.69,

Note that using a binary search (bisection) one could limit the version range.



If I understand the point you're making:

If testing for this problem was conducted with versions between 9.0.33 
and 9.0.69, the number of versions that could have caused the problem 
would be more limited which would simplify finding the cause.


-Terence Bandoian

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat for Apple silicon coming soon?

[m...@cvkimball.com]

Dear Folks,

I installed Java JDK 17 and Tomcat 10.1 on my better half's Mac Pro 
M1-based processor. It ran without problems!


Thanks,

Chris


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat for Apple silicon coming soon?

[m...@cvkimball.com]

Dear Folks,

Thanks to all for your assistance!

Best wishes,

Chris Kimball


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat for Apple silicon coming soon?

[m...@cvkimball.com]

I'd like to run Tomcat on one of the new Apple products based on the 
Apple Mac silicon ARM64 architecture.


Is a Tomcat release, preferably Tomcat 10.1, for Mac silicon likely in 
the near future?


Thanks,

Chris Kimball

Redding, CT


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Aw: Tomcat/Java app timezone radomly changes during operation.

[Terence M. Bandoian]

On 10/27/2022 6:27 PM, Peter Rader wrote:

Hi David,

is it a moving server? We had similar issues on a airborn server crossing 
nation-borders rapidly.

10 minutes is unusual. The lowest timezone-change is 15 minutes afaik.

Kind regards


Hi all,

I've experienced an issue since the morning of the 21st that I'm
hoping to get some direction on for where to look.

An app uses the date/time to set a timeout for a password reset.
This had been working fine for years and suddenly it failed. A restart of
tomcat allowed it to work for a day, then 12 hours, then 5 hours, then 1 hr
and now is averaging a 10 minute or so working duration between tomcat
restarts.

Changing the logging in the app showed that the issue is due to it
sending UTC to the DB while it is broken. Restarting Tomcat results in CDT
being sent for a while until randomly it switches again.

RHEL 7.9, jvm 1.8.0_231-b11, Tomcat 9.0.29
ntp is on, chrony is syncing, Java states correct time when queried
however unsure if it's JDK or JRE when targeted. OS time is good.

When I redeploy the app, log timestamps for the app are in UTC as well
until restarting tomcat. During the issue the log timestamp remains in
CDT as expected, even though values passed are UTC.

I have explicitly defined the timezone in setenv.sh with no change in
behavior.

Any thoughts as what to investigate are greatly appreciated.

Thanks,
David


Have you tried setting the JVM time zone with an environment variable or JVM 
argument or with TimeZone.setDefault? I think Mark Thomas mentioned earlier 
that Tomcat may invoke TimeZone.setDefault.

What do mean when you say "sending UTC to the DB while it is broken"? Are you populating 
a date/time, time or timestamp column? Sending a date or time value for some other purpose? What is 
"sending UTC to the DB"?

Also, what do you mean by "broken"? While what is broken?

It isn't clear to me what's happening. Is the O/S time zone getting changed? 
Does your app run outside of Tomcat? Is your app communicating directly with 
the database? Is this a Java app?

-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/8/2022 9:45 AM, Berneburg, Cris J. - US wrote:

2. Also, some digest messages are blank for me, but other
folks' replies to them are not.  It's often original messages
from specific users.  Maybe we can compare what we see.
Not using multiple client apps, I don't know if the blankness
is due to client app misinterpretation or if the problem
originates on the server.  I have not been keeping track of
how long this has been happening, but it seems to be a
"recent" issue, at least for me.  FYI, I use MS Outlook on Exchange Server.

Well, that's ironic.  :-)  My own messages in digest are blank!

--
Cris Berneburg
CACI Senior Software Engineer




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




Hi, Cris-

That's funny!

I don't think we can do anything about base64-encoded messages for now. 
For some other content transfer encodings, inserting a blank line at the 
beginning of the content seems to help.


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/8/2022 8:55 AM, Berneburg, Cris J. - US wrote:

Hi Terence

I have similar issues.


First, I was suddenly unable to send e-mail to the list using an
e-mail address that I have used on the list since at least 2005,
as mentioned above. I got around this by (re)subscribing to both
users and users-digest. This may be why you found my e-mail
address listed twice as a subscriber.
What isn't clear is whether a subscription to the list in the non-
digest form is now required to send messages to the list. (I was
previously subscribed to the digest only and had been able to
send messages to the list.) I should be able to test this without
too much trouble.

1. I stopped being able to reply to the digest after being subscribed for a few years.  Thanks for 
the idea about subbing to the "users" messaging service.  At Mark's suggestion, I opened 
a Jira ticket, which is still unresolved, "Subscriber Reply Posts to users@tomcat.apache.org 
Bounced".  https://issues.apache.org/jira/browse/INFRA-23619  I now see individual messages 
from myself since subscribing to that service (in addition to the digest).


Second, some attachments in the digest are still not displayed
in Thunderbird (shown as blank).I previously mistakenly reported
that some digest attachments were not displayed in gmail but that
looks to have been due to operator error as I'm now able to see
attachments in gmail including those shown as blank in Thunderbird.

2. Also, some digest messages are blank for me, but other folks' replies to them are not. 
 It's often original messages from specific users.  Maybe we can compare what we see.  
Not using multiple client apps, I don't know if the blankness is due to client app 
misinterpretation or if the problem originates on the server.  I have not been keeping 
track of how long this has been happening, but it seems to be a "recent" issue, 
at least for me.  FYI, I use MS Outlook on Exchange Server.

--
Cris Berneburg
CACI Senior Software Engineer




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




Hi, Cris-

Thanks for creating the JIRA issue about not being able to send messages 
to the list. From the comments on the issue, it appears they've 
identified a problem.


I created an issue for the blank digest messages:

https://issues.apache.org/jira/browse/INFRA-23675

which appears to be due a missing CRLF sequence following the header 
section. It's currently "WAITING FOR INFRA" so I don't think anyone has 
had a chance to look at it.


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/7/2022 1:35 AM, Mark Thomas wrote:

On 07/09/2022 04:22, Terence M. Bandoian wrote:

It looks like there's something going on with the CRLF sequence that 
should separate the header section from the body in digest 
attachments. However, it's difficult to tell where it's happening.


 From RFC 5322:

    A message consists of header fields (collectively called "the header
    section of the message") followed, optionally, by a body. The header
    section is a sequence of lines of characters with special syntax as
    defined in this specification.  The body is simply a sequence of
    characters that follows the header section and is separated from the
    header section by an empty line (i.e., a line with nothing preceding
    the CRLF).

In Thunderbird, in every attachment that is displayed as blank or is 
missing a leading portion of the message, there is no empty line 
between the header section and the body in the message source.


In gmail, those attachments are displayed, mostly, but when I 
download the source, there is no empty line separating the header 
section from the body. I say mostly because, in some cases, gmail 
does not display a leading portion of the message, but starts after 
the first blank line.


This suggests that the digest is not including empty lines between 
the header section and body of attachments. I found a couple of 
digests from 2020 and, in all attachments, an empty line was included 
between the header section and body.


Has the digest code changed recently?


Thanks for looking into this.

ezmlm (the software that runs the mailing lists) was updated around 
the time you first reported these problems.


Please raise the issue of the missing line with the ASF infrastructure 
team as they manage ezmlm for all ASF projects.


Thanks again,

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Done.

-Terence


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 9/6/2022 6:00 PM, Terence M. Bandoian wrote:

On 8/23/2022 1:47 AM, Mark Thomas wrote:

On 23/08/2022 02:45, Terence M. Bandoian wrote:
Recently, message attachments that appear blank in my e-mail client 
have been included in the Tomcat users mailing list digest.  Some 
users' messages are normally not blank (e.g. Tomcat committers and 
others). Messages from other users are.  Replies to "blank" messages 
by users whose messages are not blanked include the original 
message.  My e-mail client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear 
blank in GMail.  However, the attachments do include data which may 
be accessed by viewing the message source.


Has anyone else experienced this?


I haven't. I use Thunderbird as an email client.


Is this something that can be fixed by anyone on this list?


I don't think it is purely a list level configuration issue. I 
suspect a combination sender's email client, list server behaviour 
(possibly digest related) and receiver's email client.


What I would recommend is sending emails in plain text ("proper" 
plain text - not a plain text part in a multi-part message).



Should it be reported on the Tomcat bugzilla or somewhere else?


If you can show that the ASF list software is violating a relevant 
RFC then you can raise an issue with the ASF infrastructure team via 
the ASF Jira instance. That said, my experience is that it is email 
clients that tend to play fast and loose with the RFCs.


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on 
this list since at least 2005.  I receive the following error reply:


I've checked the list subscription and you appear to be listed twice. 
I'm not sure if that is causing issues so I have removed one of the 
subscriptions.


Mark





Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or 
an address in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If 
so, in what way?


-Terence Bandoian




Hi, Mark-

Thanks for looking into this. It appears there were/are two problems.

First, I was suddenly unable to send e-mail to the list using an 
e-mail address that I have used on the list since at least 2005, as 
mentioned above. I got around this by (re)subscribing to both users 
and users-digest. This may be why you found my e-mail address listed 
twice as a subscriber.


What isn't clear is whether a subscription to the list in the 
non-digest form is now required to send messages to the list. (I was 
previously subscribed to the digest only and had been able to send 
messages to the list.) I should be able to test this without too much 
trouble.


Second, some attachments in the digest are still not displayed in 
Thunderbird (shown as blank).I previously mistakenly reported that 
some digest attachments were not displayed in gmail but that looks to 
have been due to operator error as I'm now able to see attachments in 
gmail including those shown as blank in Thunderbird.


I'll keep looking at this and report back to the list if I learn 
anything useful.


Thanks again for your time and effort.

-Terence Bandoian



 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-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






It looks like there's something going on with the CRLF sequence that 
should separate the header section from the body in digest attachments. 
However, it's difficult to tell where it's happening.


From RFC 5322:

   A message consists of header fields (collectively called "the header
   section of the message") followed, opti

Re: Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

On 8/23/2022 1:47 AM, Mark Thomas wrote:

On 23/08/2022 02:45, Terence M. Bandoian wrote:
Recently, message attachments that appear blank in my e-mail client 
have been included in the Tomcat users mailing list digest.  Some 
users' messages are normally not blank (e.g. Tomcat committers and 
others). Messages from other users are.  Replies to "blank" messages 
by users whose messages are not blanked include the original 
message.  My e-mail client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear blank 
in GMail.  However, the attachments do include data which may be 
accessed by viewing the message source.


Has anyone else experienced this?


I haven't. I use Thunderbird as an email client.


Is this something that can be fixed by anyone on this list?


I don't think it is purely a list level configuration issue. I suspect 
a combination sender's email client, list server behaviour (possibly 
digest related) and receiver's email client.


What I would recommend is sending emails in plain text ("proper" plain 
text - not a plain text part in a multi-part message).



Should it be reported on the Tomcat bugzilla or somewhere else?


If you can show that the ASF list software is violating a relevant RFC 
then you can raise an issue with the ASF infrastructure team via the 
ASF Jira instance. That said, my experience is that it is email 
clients that tend to play fast and loose with the RFCs.


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on 
this list since at least 2005.  I receive the following error reply:


I've checked the list subscription and you appear to be listed twice. 
I'm not sure if that is causing issues so I have removed one of the 
subscriptions.


Mark





Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or 
an address in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If 
so, in what way?


-Terence Bandoian




Hi, Mark-

Thanks for looking into this. It appears there were/are two problems.

First, I was suddenly unable to send e-mail to the list using an e-mail 
address that I have used on the list since at least 2005, as mentioned 
above. I got around this by (re)subscribing to both users and 
users-digest. This may be why you found my e-mail address listed twice 
as a subscriber.


What isn't clear is whether a subscription to the list in the non-digest 
form is now required to send messages to the list. (I was previously 
subscribed to the digest only and had been able to send messages to the 
list.) I should be able to test this without too much trouble.


Second, some attachments in the digest are still not displayed in 
Thunderbird (shown as blank).I previously mistakenly reported that some 
digest attachments were not displayed in gmail but that looks to have 
been due to operator error as I'm now able to see attachments in gmail 
including those shown as blank in Thunderbird.


I'll keep looking at this and report back to the list if I learn 
anything useful.


Thanks again for your time and effort.

-Terence Bandoian



 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-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

Re: [ANN] New committer: Han Li

[Terence M. Bandoian]

On 9/6/2022 2:38 AM, Mark Thomas wrote:

On behalf of the Tomcat committers I am delighted to announce that
Han Li (lihan) has been voted in as a new Tomcat committer.

Please join me in congratulating Han.

Kind regards,

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Well done!

-Terence Bandoian



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Fwd: users Digest 17 Aug 2022 09:26:06 -0000 Issue 14393 - "BLANK" DIGEST MESSAGE ATTACHMENTS

[Terence M. Bandoian]

Recently, message attachments that appear blank in my e-mail client have 
been included in the Tomcat users mailing list digest.  Some users' 
messages are normally not blank (e.g. Tomcat committers and others).  
Messages from other users are.  Replies to "blank" messages by users 
whose messages are not blanked include the original message.  My e-mail 
client has not changed.


This message is a forward of a digest in which all of the message 
attachments appear blank in my e-mail client.  They also appear blank in 
GMail.  However, the attachments do include data which may be accessed 
by viewing the message source.


Has anyone else experienced this?  Is this something that can be fixed 
by anyone on this list?  Should it be reported on the Tomcat bugzilla or 
somewhere else?


In addition, I have been unable to send e-mail to 
users@tomcat.apache.org from tere...@tmbsw.com which I have used on this 
list since at least 2005.  I receive the following error reply:



Hi. This is the qmail-send program at apache.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Must be sent from an @apache.org address or a subscriber address or an address 
in LDAP.


Has something changed?  Do I need to reconfigure my mail server?  If so, 
in what way?


-Terence Bandoian


 Forwarded Message 
Subject: users Digest 17 Aug 2022 09:26:06 - Issue 14393
Date: 17 Aug 2022 09:26:06 -
From: users-digest-h...@tomcat.apache.org
Reply-To: Tomcat Users List 
To: users@tomcat.apache.org




users Digest 17 Aug 2022 09:26:06 - Issue 14393

Topics (messages 275525 through 275527)

Re: Getting error on Tomcat Start
275525 by: Mohan T
275526 by: Thomas Meyer
275527 by: Mohan T

Administrivia:

-
To post to the list, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-digest-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-digest-h...@tomcat.apache.org

--



--- Begin Message ---
--- End Message ---
--- Begin Message ---
--- End Message ---
--- Begin Message ---
--- End Message ---

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Supporting languages

[M. Osama Alghwell]

Hi,
I have an Oracle application and database. I am using Tomcat 9 but
unfortunately Arabic language couldn't be used. Any help?

M. Alghwell

Re: Fwd: tomcat 9.50 - rewrite rule question

[Terence M. Bandoian]

On 3/19/2022 1:03 AM, rupali singh wrote:

Hi Team,

We are using tomcat 9.54 version.
Need help in rewriting rule.

background   : We have an Oracle apex server ( version 21.1)  and tomcat is
installed on the same server. We have F5 url which redirects to apex
installed on tomcat  eg https://xyz.ae/apex/f?p=1001
   so xyz.ae is published on our F5 which
redirects internally to tomcat server on port 8080.

we want to redirect  https://xyz.ae/apex/f?p=1001
   to
  https://xyz.ae/apex/myapp    as it's difficult
for business users to remember f?p=1001 

i have prepared context.xml and rewrite.config rule but redirection not
working and there is no error in catalina.log

in access log we are getting 404.

i have tried steps mentioned in
https://stackoverflow.com/questions/38618473/tomcat-9-rewrite-with-ords-and-oracle-apex

rewrite.config content

RewriteCond %{REQUEST_URI} ^/myapp$
RewriteRule ^/myapp$ https://xyz.ae/apex/myapp [R,L]


please advise how to resolve the issue


Those look like Apache HTTPD rewrite rules. How are they supported in 
Apache Tomcat?


-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

correct usage of properties to supply database port

[Terence M. Bandoian]

On 3/11/2022 9:40 AM, Rob Sargent wrote:



On Mar 11, 2022, at 8:17 AM, Thomas Hoffmann (Speed4Trade GmbH) 
 wrote:




-Ursprüngliche Nachricht-
Von: Rob Sargent 
Gesendet: Freitag, 11. März 2022 15:14
An: Tomcat Users List 
Betreff: Re: correct usage of properties to supply database port




On Mar 11, 2022, at 6:50 AM, Mark H. Wood  wrote:

On Thu, Mar 10, 2022 at 09:40:48AM -0700, Rob Sargent wrote:

About context/context/value:  I have this context.xml. Is the value
correctly inside the outer Context?

   

  

  


  
   

I don't think you can nest s that way, and I'm not sure what
it would mean.  I would remove the inner  pair.

--
Mark H. Wood
Lead Technology Analyst

Thanks. I’ll take a look at that. I don’t see any related error messages but 
I’ll
check my logging.
Thanks



Nesting of Context is not allowed as far as I know.
The documentation tells, which parent nodes/Elements are allowed , e.g. valve:
https://tomcat.apache.org/tomcat-10.0-doc/config/valve.html
only allowed in host, Context or Engine Element.



Ok. Thanks for digging in to that. I am not able to investigate (or correct) at 
the moment


Related warnings from your initial post:

   WARNING: No rules found matching [Context/Context/Valve]

   WARNING: No rules found matching [Context/Context]

-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9 doesn't shutdown cleanly

[Terence M. Bandoian]

On 11/30/2021 8:40 AM, Simon Matter wrote:

Hi Chris,

Thank you for the quick reply.


Simon,

On 11/30/21 08:21, Simon Matter wrote:

I'm running an application on Tomcat 9.0.55 on x86_64 Linux with OpenJDK
JRE-11.0.13+8 and have problems shutting down Tomcat in certain ways.

When I shutdown Tomcat via 'catalina.sh stop', it shuts down mostly
(most
threads are gone) but send a thread dump to catalina.out and is later
killer by an OS signal.

This should only happen if you have CATALINA_PID defined. Are you indeed
defining that environment variable?

catalina.sh has this code in it, which is probably what you are seeing:

echo "To aid diagnostics a thread dump has been written to
standard out."
kill -3 `cat "$CATALINA_PID"`


That's true, I have CATALINA_PID defined when the call of "catalina.sh
start" is done. So yes, the script will kill the java process if it
doesn't terminate.


When shutting down Tomcat via the shutdown listener on port 8005, it
also
shuts down mostly but without the thread dump in catalina.out. Sending
SIGTERM later to the still running java process terminates it.

Right: when you manually connect to the shutdown port and send
"SHUTDOWN" (or whatever), it asks Tomcat to shut down but doesn't send a
signal. You have to do that manually, too.

On a test host, when I send "SHUTDOWN" to the shutdown listener, Tomcat
shuts down and the Java VM terminates.

Only on this host with the application, when I send "SHUTDOWN" to the
shutdown listener, Tomcat shuts down but the Java VM doesn't terminate.


So both methods somehow terminate Tomcat partly but not completely.

You have one or two of the following issues:

1. You have a non-daemon thread running
2. You have an unusually long shutdown process that just takes "too long"

The good news is that the thread-dup can answer that question: what's in
the thread dump that is generated when you run "catalina.sh stop"?


When simply sending SIGTERM on the OS level, Tomcat shuts down cleanly
and
terminates without issues.

One thing in common is that I always see these messages while shutting
down:

30-Nov-2021 13:59:36.985 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class
[sun.rmi.registry.RegistryImpl_Stub] and value
[RegistryImpl_Stub[UnicastRef [liveRef:
[endpoint:[157.161.91.47:2071](local),objID:[0:0:0, 0]. This RMI
Target has been forcibly removed to prevent a memory leak.
30-Nov-2021 13:59:36.987 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class [com.sun.proxy.$Proxy51] and
value
[Proxy[ShopdbCacheSynchronizer,RemoteObjectInvocationHandler[UnicastRef
[liveRef:
[endpoint:[157.161.91.47:1096](local),objID:[-6f4b2f9d:17d70eb1ef4:-7ffd,
-4005526521234186948]]. This RMI Target has been forcibly removed to
prevent a memory leak.
30-Nov-2021 13:59:36.987 SEVERE [main]
org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesRmiTargets
Found RMI Target with stub class class
[sun.rmi.registry.RegistryImpl_Stub] and value
[RegistryImpl_Stub[UnicastRef [liveRef:
[endpoint:[157.161.91.47:1096](local),objID:[0:0:0, 0]. This RMI
Target has been forcibly removed to prevent a memory leak.

Why do the three methods to shutdown Tomcat differ and how can I make
'catalina.sh stop' or the shutdown listener work the same way like
sending
the OS signal.

What's the difference? You don't want the thread dump in your
catalina.out? That's supposed to be helpful in debugging why your
shutdown isn't clean. It sounds like you are saying "help me with my
unclean shutdown; please get rid of the debugging information that is
trying to help me!".


I've tried, beside a lot of other things, to set
skipMemoryLeakChecksOnJvmShutdown="true" in context.xml but it seems to
change nothing at all.

Tomcat will never kill your non-daemon thread(s) from inside the VM.
Since you are using a CATALINA_PID environment variable (and, therefore,
a pid-file), the shutdown process is sending the TERM signal. It's also
possibly sending a KILL signal, depending on whether or not the TERM
worked and if -force was supplied on the command-line.

Unfortunately I am not an insider when it comes to Java, so I'm not sure
what a non-daemon thread means here? Can these be threads started by our
application which are non-daemon threads? So they will be terminated with
SIGTERM to the Java VM but not using the shutdown listener?

I'll paste a thread dump below.

Thanks,
Simon

Full thread dump OpenJDK 64-Bit Server VM (11.0.13+8 mixed mode):

Threads class SMR info:
_java_thread_list=0x55a49ac4ba60, length=18, elements={
0x7f1ac0148800, 0x7f1ac014a800, 0x7f1ac015f800,
0x7f1ac0161800,
0x7f1ac0164000, 0x7f1ac0168800, 0x7f1ac016a000,
0x7f1ac01ad800,
0x7f1ac0258000, 0x7f1ac0311000, 0x7f1ac0318000,
0x7f1ac031a000,
0x7f1ac25d6800, 0x7f1ac25fe800, 

Re: Timestamp Error

[Terence M. Bandoian]

On 8/27/2021 2:31 PM, Jerry Malcolm wrote:


On 8/27/2021 1:30 PM, Mark Eggers wrote:

On 8/27/2021 11:16 AM, Jerry Malcolm wrote:


On 8/27/2021 11:55 AM, Christopher Schultz wrote:

Mark and Jerry,

On 8/26/21 22:03, Mark Eggers wrote:

Jerry,

On 8/26/2021 6:35 PM, Jerry Malcolm wrote:
I am encountering a weird problem. I'm getting the following SQL 
error on an INSERT command.


com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data 
truncation: Incorrect datetime value: '1969-12-31 18:00:00.0' for 
column...

The column is a TIMESTAMP in mySQL.

I pasted the SQL statement directly out of my log into 
phpMyAdmin, and it worked.  When I change the date to '2021-08-27 
01:03:18.1077537'

it also works.

I tried it on my production AWS server.  The server timezone was 
different but same failure with '1970-01-01 00:00:00.0'


I'm running Win10 with latest updates (AWS Linux 2 on production)
TC 9.0.16
mysql-connector-java-8.0.26.jar
mysql5.7.19

I found some discussions on the web from around 2016. But it just 
said to update the connector and TC. My versions are already way

past 2016 versions.

My biggest concern is that some dates work and some don't.  If I 
have to avoid dates that fail, I can probably do that.  But right 
now,
I don't know what dates are going to work and what dates are 
going to fail.


Am I missing something obvious?  I've never had a SQL statement 
that failed consistently on TC but worked when pasted into 
phpMyAdmin.


Suggestions?

Thanks.

Jerry


There is a setting in the driver called something like "null means 
zero datetime" which may confuse the heck out of TIMESTAMP columns, 
which expect a UNIX-epoch timestamp value.


The datetime value '1969-12-31 18:00:00.0' you may recognize as the 
start of the UNIX Epoch minus 6 hours, which suggests to me that 
your system is running in Us-Mountain Time, 6 hours behind UTC in 
the summer.


I would bet that you are trying to insert a NULL into a TIMESTAMP, 
and that your driver is using MDT as your time zone, trying to 
convert NULL -> 1970-01-01 00:00:00 UTC -> 1969-12-31 18:00:00 MDT 
-> boom, since the minimum allowed TIMESTAMP value is 1970-01-01 
00:00:00.


Might I ask why you are using a TIMESTAMP field? IMHO they aren't 
good for much...


-chris

Chris,  thanks for the info.  Why timestamp?  Unfortunately, some of 
this code was written 20+ years ago when I was a lot less 
knowledgeable... But too difficult to change now.


I'm not inserting nulls.  Always a quoted date/time string.

You are correct about the timezone.  That's on my dev laptop, and I 
never got around to setting the timezone stuff correctly on my my 
dev machine.  However, my production server (Linux) does have the 
timezones all set correctly.  My insert statement has a value of 
"new Timestamp(0).toString()".  On the production server, this 
becomes '1970-01-01 00:00:00.0' and it still fails on production.


Is the jdbc driver enforcing the minimum timestamp value? mySQL 
accepts 1969-12-31 18:00:00.0 in the insert statement. mySQL may be 
adjusting the time +6 on my laptop back up the epoch value before 
storing it.  But the situation still remains that the same insert 
statement works on phpMyAdmin and fails on TC.


The timezone thing is just adding unnecessary complexity to the 
problem.  The production server fails on TC with '1970-01-01 
00:00:00.0' in the insert statement, but works with that value when 
inserted into mySQL pasting the insert statement into phpMyAdmin.


The exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation.  
Is the driver detecting this and generating the exception?  Or does 
the insert statement get all the way to mySQL and mySQL fails back 
to the driver followed by the driver throwing the exception?


Jerry


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



https://docs.oracle.com/javase/8/docs/api/java/sql/Timestamp.html

See the constructor: public Timestamp(long time)

. . . just my two cents
/mde/

|Timestamp 
(long time)| 


Constructs a |Timestamp| object using a milliseconds time value.
|time| - milliseconds since January 1, 1970, 00:00:00 GMT. A negative 
number is the number of milliseconds before January 1, 1970, 00:00:00 
GMT.


This says that a timestamp can be before the epoch, no minimum time, 
which agrees with what I'm seeing via phpMyAdmin.  Which means that 
what I'm providing in the sql insert statement should be accepted 
regardless of timezone factors. Seems to me there's a bug in the TC 
driver (??)  And the error message I'm getting says "data truncation", 
which at best is incorrect wording.  Not sure how any truncation could 
occur on a date string that parses to (long)0.  I thought the .0 
fractions of a second on the end of the string could be the cause of 

Upgrading Tomcat from 7.0.34 to 8.0.53

[Nelligan, Steven M]

I am in the process of upgrading our systems from Tomcat 7.0.34 to Tomcat 
8.0.53 and Java 7 to Java 8

I'm not sure if this is a java 8 or a Tomcat 8 issue.

We have several application which use EJBs.  These are not working.  I have no 
experience in EJB's and having problems trying to figure out what is happening.

Because of my lack of knowledge on EJB's the following may be rambling.

Via the java debugger, I am able to determine that the EJB is not be 
initialized.

Example of a class .
...
@EJB
CustomerService customerService;
@EJB
OrderStatusService orderStatusService;
@EJB
SettingService settingService;
@EJB
ErrorLogService errorLogService;
@EJB
EsbBroker esbBroker;
...
 orderStatusService.createOrderStatus(orderRequest);
...

On the original server orderStatusService has a value, but in the new server 
the value is null.

Is there something with Tomcat 8/Java 8 I need to change to get the code to 
work correctly?

If this is not a Tomcat8 issue, please let me know and I can try to follow 
other avenues to get help.

Thanks in advance,
-Steve Nelligan


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

[Terence M. Bandoian]

On 8/26/2020 11:27 PM, Pratik Shrestha wrote:

Dear all,

Thanks for so many replies and your discussions.

For me, there are two options for the fix which I am not able  to make them
work.

1. Either show 'ERR_EMPTY_RESP' like old Tomcat version 7 used to show. As
far as I know, with Tomcat 7 giving that error, Qualys did not use to show
this vulnerability.
2. *Best is to do a redirect* when Tomcat sees error 400 to https URL. Like
in Apache, we can add below.
'ErrorDocument 400 "*https*://xxx.xxx.xxx.xxx"
But as understood, redirect only works with error 3XX and ErrorDocument
feature is not there in Tomcat yet.

@Jon, yes, what we want is redirect on error 400 (explained in #2 above).
And please ignore port 9443.

Regards,
Pratik


With HTTPD rewrite, whether or not the request is encrypted or sent to 
the correct port can be detected and the request redirected as 
appropriate. Maybe the same can be done with the rewrite valve used with 
Tomcat.


-Terence Bandoian


On Thu, Aug 27, 2020 at 3:16 AM 
wrote:


What is the URL they are testing? Is there a reason there is a 9443 port
open? How about adding a blank page with a redirect, or use the rewrite
valve to rewrite to https?


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the addressee,
you must not use, copy, disclose, or take any action based on this message
or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this
message. Thank you for your cooperation.


-Original Message-
From: Christopher Schultz 
Sent: Wednesday, August 26, 2020 2:56 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat v9 - Insecure transport vulnerability reported by
Qualys

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/26/20 13:59, Mark Thomas wrote:

On 26/08/2020 17:50, Christopher Schultz wrote:

On 8/26/20 05:27, Mark Thomas wrote:

On 26/08/2020 08:14, Martin Grigorov wrote:

Hi,

On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha
 wrote:


Thanks for reply,

Hi Peter - it complains on port 8443 which belongs to Tomcat.

Hi Mark - Yes. making HTTP request on HTTPS is wrong. But this
security vulnerability is given to us by Qualys scan.
It tries to post plain HTTP request on HTTPS port and then gets
error message "Bad Request. This combination of host and port
requires TLS." which is security loop hole for Qualys.

On what basis?
I fail to see any security issue here other than "Qualys says so"
which is not a valid description of a security vulnerability.

My guess is that this is some form of "server fingerprinting"
that they are claiming, like "Zomg! It says Server:
Apache-Coyote/1.1! You are $uper vulnerable to 0days, now!".

The entire response, including headers is,

= HTTP/1.1 400 Content-Type: text/plain;charset=UTF-8
Connection: close

Bad Request This combination of host and port requires TLS. =


Pratik, can you please be very clear about what the actual complaint
is? Are they objecting to one or more of the
following:

0. Any legible response at all (meaning they just want a
connection-drop response) 1. Server: Apache-Coyote/1.1 response
header 2. Predictable / stock text (e.g. "Bad Request. This
combination of host and port requires TLS." identifies the server as
Tomcat v.x.y or later) 3. Actual Tomcat version number in response


Absent a description of how this can be exploited (and I'll be very
surprised if this can be exploited), there is no security issue here
and Tomcat will not be making any changes.

It seems reasonable to (configurably) strip-out version information
if there is anything in there... which there probably is not.

Correct, there isn't.


I'm interested in having Tomcat be able to pass these (admittedly
stupid) security requirements,

I have no interest in adding bloat to Tomcat so it can pass so called
security requirements that have no relevance to actual security. Those
sort of changes are the sort that get me starting to think about using
a veto.

Understood. But what does the OP have in terms of options at this point?

1. Ignore the complaint (probably not possible) 2. Request a waiver for
this issue (probably not possible, or at least would require 10 years of
red tape) 3. Front the server with httpd + "ErrorDocument 400" (which ... I
think will *also* reply with a plaintext response, right?) 4. Switch to
Jetty

I'm trying to avoid "the easiest thing" which is probably to switch to
Jetty. I know our "customers" don't pay for Tomcat, but losing a "customer"
sucks.


so maybe we could have a setting on the  that can allow

RE: SSL error [EXTERNAL]

[Beard, Shawn M.]

I was able to resolve this. I used keytool to create a new keystore/trust 
store, then imported the previous truststore that had all the CA certs in it. 
That seemed to work. So even though the previous truststore had the certs in it 
and was not empty, it must have had some kind of linking problem maybe?



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: john.e.gr...@wellsfargo.com.INVALID 
Sent: Friday, June 26, 2020 1:32 PM
To: users@tomcat.apache.org
Subject: RE: SSL error [EXTERNAL]

** CAUTION: External message


Shawn,


-Original Message-
From: Beard, Shawn M. 
Sent: Friday, June 26, 2020 11:57 AM
To: Tomcat Users List 
Subject: RE: SSL error [EXTERNAL]

The code is calling a new webservice. It has godaddy as its ca signer. It was 
getting the error before I added those java options. Those java options were my 
attempt to resolve it. Ive also tried adding the godaddy ca certs to java's 
cacert file without those java options. Same result.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: calder 
Sent: Friday, June 26, 2020 11:45 AM
To: Tomcat Users List 
Subject: Re: SSL error [EXTERNAL]

** CAUTION: External message


In Fri, Jun 26, 2020, 10:37 Beard, Shawn M. 
wrote:

> We are running tomcat-7.0.52(old I know) and java 1.7.0_80.
>

yea, BOTH are very old.

When the app makes calls to an external webservice. It keeps throwing this
> error:
>
> javax.net.ssl.SSLException : javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
>
[1]

> I have this in the java options and have confirmed the proper CA certs
> for this webservice is in the truststore. Any ideas?
>
-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.trustStoreType=jks
>

Did this runtime EVER work?

If yes, "what" changed?



[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty__;!!Li8W9_Um1Taa!uk48yx6ZQNHjmcqPmjBlJDFCcCWu6HMZu3OI_Yau1oJ4CBGoaFzI0pfKTaIrqOGk$
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.
B CB  [  
X  ܚX KK[XZ[  \ \  ][  X  ܚX P X ]  \X K ܙ B  ܈Y][ۘ[  [X[  
K[XZ[  \ \  Z[ X ]  \X K ܙ B

That error message comes from PKIXParameters.setTrustAnchors().  I was able to 
reproduce the problem with an empty trust store.  I also tried a trust store 
with the wrong certs but got a different error.

With -Djavax.net.debug=ssl, you should see output like this:

trustStore is: /path/to/trust.jks
trustStore type is: jks
trustStore provider is:
the last modified time is: Fri Jun 26 13:27:52 CDT 2020 Reload the trust store 
Reload trust certs Reloaded 1 trust certs adding as trusted cert:

Followed by a list of certs found in the store.

Is that what's happening in your case?

John

Т ХF  V 
7V'67&  R   â W6W'2 V 7V'67&  F  6B 6 R  Фf "FF F    6    G2 
R   â W6W'2ֆV  F  6B 6 R  Р

RE: SSL error [EXTERNAL]

[Beard, Shawn M.]

The code is calling a new webservice. It has godaddy as its ca signer. It was 
getting the error before I added those java options. Those java options were my 
attempt to resolve it. Ive also tried adding the godaddy ca certs to java's 
cacert file without those java options. Same result.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: calder 
Sent: Friday, June 26, 2020 11:45 AM
To: Tomcat Users List 
Subject: Re: SSL error [EXTERNAL]

** CAUTION: External message


In Fri, Jun 26, 2020, 10:37 Beard, Shawn M. 
wrote:

> We are running tomcat-7.0.52(old I know) and java 1.7.0_80.
>

yea, BOTH are very old.

When the app makes calls to an external webservice. It keeps throwing this
> error:
>
> javax.net.ssl.SSLException : javax.net.ssl.SSLException:
> java.lang.RuntimeException: Unexpected error:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty
>
[1]

> I have this in the java options and have confirmed the proper CA certs
> for this webservice is in the truststore. Any ideas?
>
-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks
> -Djavax.net.ssl.trustStorePassword=
> -Djavax.net.ssl.trustStoreType=jks
>

Did this runtime EVER work?

If yes, "what" changed?



[1]
https://urldefense.com/v3/__https://stackoverflow.com/questions/6784463/error-trustanchors-parameter-must-be-non-empty__;!!Li8W9_Um1Taa!uk48yx6ZQNHjmcqPmjBlJDFCcCWu6HMZu3OI_Yau1oJ4CBGoaFzI0pfKTaIrqOGk$
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

SSL error

[Beard, Shawn M.]

We are running tomcat-7.0.52(old I know) and java 1.7.0_80.  When the app makes 
calls to an external webservice. It keeps throwing this error:

javax.net.ssl.SSLException : javax.net.ssl.SSLException: 
java.lang.RuntimeException: Unexpected error: 
java.security.InvalidAlgorithmParameterException: the trustAnchors parameter 
must be non-empty

I have this in the java options and have confirmed the proper CA certs for this 
webservice is in the truststore. Any ideas?

-Djavax.net.ssl.trustStore=/path/to/truststore/tomcatTrustStore.jks 
-Djavax.net.ssl.trustStorePassword= -Djavax.net.ssl.trustStoreType=jks





Shawn Beard • Sr. Systems Engineer
Middleware Engineering

[cid:image75dd5a.PNG@4f1b1b38.44a2aecd]


 3840 109th Street Urbandale, IA 50322
 Phone: +1-515-564-2528
 Email: sbe...@wrberkley.com
 Website: 
berkleytechnologyservices.com

Technology Leadership Unleashing Business Potential



CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

RE: Changing the Java using by Tomcat [EXTERNAL]

[Beard, Shawn M.]

No we do this and use AdoptOpen JDK. If you are setting JAVA_HOME in any tomcat 
config like a setenv file or catalina file make sure to change those to point 
to the install of AdoptOpenJDK.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: Reddy, Tippana Krishnanandan 
Sent: Wednesday, May 06, 2020 3:56 AM
To: users@tomcat.apache.org
Cc: Reddy, Tippana Krishnanandan 
Subject: Changing the Java using by Tomcat [EXTERNAL]

** CAUTION: External message


Hi All,

We are using tomcat 9.0.6 and we want to change existing JAVA used by tomcat 
and replace it Adopt openJDK without uninstalling the tomcat.

Is this possible? if so can anyone please send us details how to approach this.

Thanks in Advance

Regards,
Krishna


This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and is protected by law. If you 
are not the intended recipient, you should delete this message and any 
disclosure, copying, or distribution of this message, or the taking of any 
action based on it, by you is strictly prohibited.

Deloitte refers to a Deloitte member firm, one of its related entities, or 
Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte member firm is a 
separate legal entity and a member of DTTL. DTTL does not provide services to 
clients. Please see 
https://urldefense.com/v3/__http://www.deloitte.com/about__;!!Li8W9_Um1Taa!qPb1FKVzHToxHSLz8lz3Z_cgP48BJSrFfuEWiUC2_s3zCu2zehglRR-fzDCaeLNP$
  to learn more.

v.E.1
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Upgrading from 9.0.20 to 9.0.34 AJP connector issue [EXTERNAL]

[Beard, Shawn M.]

My workers is identical to yours and it works.

Here is our connector config that is working.

Might want to try removing address="127.0.0.1" and/or 
tomcatAuthentication="false"

The fix for the Ghostcat vulnerability created some config challenges on the 
ajp protocol. I'm pretty sure it’s the tomcatAuthentication you need to remove.





Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: Darryl Philip Baker 
Sent: Thursday, April 30, 2020 7:00 AM
To: Tomcat Users List 
Subject: Upgrading from 9.0.20 to 9.0.34 AJP connector issue [EXTERNAL]

** CAUTION: External message


I am trying to upgrade a development environment from 9.0.20 to 9.0.34 and I am 
having issues getting the tomcat-connectors-1.2.46 (mod_jk) to work in with the 
new version. The Apache HTTPD configuration remains unchanged the paths pass 
through a symbolic link I change to switch versions. The workers.properties 
file was copied over and is identical. I added the same definition for the AJP 
connector into server.xml. I will place the pieces I modified below.

Server.xml:



Workers.properties:
#define 1st worker using worker1
worker.list=worker1

#set properties for the worker1 worker
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009
worker.worker1.lbfactor=50
worker.worker1.cachesize=10
worker.worker1.cache_timeout=600
worker.worker1.socket_keepalive=1
worker.worker1.recycle_timeout=300

Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL  60201-3715
darryl.ba...@northwestern.edu
(847) 467-6674

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

RE: Apache tomcat 9.0.6 Compatibility with Adopt openJDK [EXTERNAL]

[Beard, Shawn M.]

We are running the Adopt Open JDK 8 and 11 builds on tomcat 9 with no issues.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: Martin Grigorov 
Sent: Tuesday, April 28, 2020 12:56 AM
To: Tomcat Users List 
Subject: Re: Apache tomcat 9.0.6 Compatibility with Adopt openJDK [EXTERNAL]

** CAUTION: External message


Hi,

On Tue, Apr 28, 2020 at 5:12 AM Reddy, Tippana Krishnanandan < 
tire...@deloitte.com> wrote:

> Hi everyone,
>
> We are using Tomcat 9.0.6 . I want to know if we have any document
> which shows the compatibility of Tomcat with Adopt openJDK.
>

Any JDK 1.8+ should be OK.
But as any other software there might be bugs in any part.
You are recommended to use latest patch versions of both Tomcat and AdoptJDK 
though. Tomcat 9.0.6 is a bit old.

Martin


>
> Thanks in Advance
>
> Regards,
> Krishna
>
>
> This message (including any attachments) contains confidential
> information intended for a specific individual and purpose, and is
> protected by law. If you are not the intended recipient, you should
> delete this message and any disclosure, copying, or distribution of
> this message, or the taking of any action based on it, by you is strictly 
> prohibited.
>
> Deloitte refers to a Deloitte member firm, one of its related
> entities, or Deloitte Touche Tohmatsu Limited ("DTTL"). Each Deloitte
> member firm is a separate legal entity and a member of DTTL. DTTL does
> not provide services to clients. Please see 
> https://urldefense.com/v3/__http://www.deloitte.com/about__;!!Li8W9_Um1Taa!sq4-qyjXXkymhJTF2EoIm2-97BD9cpG1qZCghCQIy9pZXDGGa_HQwce54KNZBMvU$
>   to learn more.
>
> v.E.1
>
CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: tomcat and ssl [EXTERNAL]

[Beard, Shawn M.]

Adding this to the JVM options worked:
-Djavax.net.ssl.trustStore=/usr/apache/tomcat/ssl/TomcatTrustStore.p12 
-Djavax.net.ssl.trustStorePassword=



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: Mark Thomas 
Sent: Monday, April 27, 2020 11:34 AM
To: users@tomcat.apache.org
Subject: Re: tomcat and ssl [EXTERNAL]

** CAUTION: External message


On 27/04/2020 17:29, Beard, Shawn M. wrote:
> This is a 3rd party app so can't do that. We need to configure tomcat to have 
> apps use a trust store just like any other java container.

That isn't the way Java SE, Java EE (now Jakarta EE), JSSE, and web 
applications work.

Tomcat has ZERO role in out-going SSL connections. Any container that claims 
otherwise is doing nothing more than setting the relevant system properties.

It sounds like setting a trust store via system properties is your only option 
(although personally I'd be raising a bug against that 3rd-party app as relying 
on system properties for configuration can be fragile).

Mark


>
>
>
> Shawn Beard
> Sr. Systems Engineer
> BTS
> +1-515-564-2528
>
> -Original Message-
> From: Mark Thomas 
> Sent: Monday, April 27, 2020 11:26 AM
> To: users@tomcat.apache.org
> Subject: Re: tomcat and ssl [EXTERNAL]
>
> ** CAUTION: External message
>
>
> On 27/04/2020 17:21, Beard, Shawn M. wrote:
>> I have an app running in tomcat 9 that makes an ssl call to an
>> external webservice.
>>
>>
>>
>> It fails with these errors in the logs:
>>
>> ERROR javax.net.ssl.SSLHandshakeException: PKIX path building failed:
>> sun.security.provider.certpath.SunCertPathBuilderException: unable to
>> find valid certification path to requested target
>>
>>
>>
>> I have this in the connectors in the server.xml.
>>
>>   keystoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
>>
>>truststoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
>>
>>keystorePass=""
>>
>>truststorePass="XXX"
>>
>>
>>
>>
>>
>> I have the root authority certs importated as trusted certs in this
>> p12 file.
>>
>>
>>
>> Any ideas?
>
> Outgoing SSL calls are nothing to do with Tomcat. Configuration in server.xml 
> will have zero impact on them. You need to code the out going call exactly 
> the same way as you would in a stand-alone Java program. My recommendation is 
> you configure the connection programmatically rather than via system 
> properties although the system properties approach should work.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
> private, privileged and confidential information belonging to the sender. The 
> information therein is solely for the use of the addressee. If your receipt 
> of this transmission has occurred as the result of an error, please 
> immediately notify us so we can arrange for the return of the documents. In 
> such circumstances, you are advised that you may not disclose, copy, 
> distribute or take any other action in reliance on the information 
> transmitted.
>
> -
> 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

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: tomcat and ssl [EXTERNAL]

[Beard, Shawn M.]

Adding this to JVM options worked

-Djavax.net.ssl.trustStore=/usr/apache/tomcat/ssl/TomcatTrustStore.p12 
-Djavax.net.ssl.trustStorePassword=XXX



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: js84 
Sent: Monday, April 27, 2020 11:33 AM
To: Tomcat Users List 
Subject: AW: tomcat and ssl [EXTERNAL]

** CAUTION: External message


Hello!

> I have an app running in tomcat 9 that makes an ssl call to an external 
> webservice.

> It fails with these errors in the logs:
> ERROR javax.net.ssl.SSLHandshakeException: PKIX path building failed:  
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
> valid certification path to requested target

> I have this in the connectors in the server.xml.
>  keystoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
>   truststoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
>   keystorePass=""
>   truststorePass="XXX"

> I have the root authority certs importated as trusted certs in this p12 file.

> Any ideas?

Outgoing SSL requests are normally using /lib/security/cacerts as 
truststore: Check if root (intermediate) certificate exists for targeted 
endpoint.

BR,
Johann


Von: Beard, Shawn M.
Gesendet: Montag, 27. April 2020 18:22
An: users@tomcat.apache.org
Betreff: tomcat and ssl

I have an app running in tomcat 9 that makes an ssl call to an external 
webservice.

It fails with these errors in the logs:
ERROR javax.net.ssl.SSLHandshakeException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target

I have this in the connectors in the server.xml.
  keystoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
   truststoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
   keystorePass=""
   truststorePass="XXX"


I have the root authority certs importated as trusted certs in this p12 file.

Any ideas?

Shawn Beard • Sr. Systems Engineer
Middleware Engineering



 3840 109th Street Urbandale, IA 50322
 Phone: +1-515-564-2528
 Email: sbe...@wrberkley.com
 Website: berkleytechnologyservices.com

Technology Leadership Unleashing Business Potential

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

RE: tomcat and ssl [EXTERNAL]

[Beard, Shawn M.]

This is a 3rd party app so can't do that. We need to configure tomcat to have 
apps use a trust store just like any other java container.



Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: Mark Thomas 
Sent: Monday, April 27, 2020 11:26 AM
To: users@tomcat.apache.org
Subject: Re: tomcat and ssl [EXTERNAL]

** CAUTION: External message


On 27/04/2020 17:21, Beard, Shawn M. wrote:
> I have an app running in tomcat 9 that makes an ssl call to an
> external webservice.
>
>
>
> It fails with these errors in the logs:
>
> ERROR javax.net.ssl.SSLHandshakeException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to
> find valid certification path to requested target
>
>
>
> I have this in the connectors in the server.xml.
>
>   keystoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
>
>truststoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
>
>keystorePass=""
>
>truststorePass="XXX"
>
>
>
>
>
> I have the root authority certs importated as trusted certs in this
> p12 file.
>
>
>
> Any ideas?

Outgoing SSL calls are nothing to do with Tomcat. Configuration in server.xml 
will have zero impact on them. You need to code the out going call exactly the 
same way as you would in a stand-alone Java program. My recommendation is you 
configure the connection programmatically rather than via system properties 
although the system properties approach should work.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

tomcat and ssl

[Beard, Shawn M.]

I have an app running in tomcat 9 that makes an ssl call to an external 
webservice.

It fails with these errors in the logs:
ERROR javax.net.ssl.SSLHandshakeException: PKIX path building failed: 
sun.security.provider.certpath.SunCertPathBuilderException: unable to find 
valid certification path to requested target

I have this in the connectors in the server.xml.
  keystoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
   truststoreFile="/usr/apache/tomcat/ssl/TomcatTrustStore.p12"
   keystorePass=""
   truststorePass="XXX"


I have the root authority certs importated as trusted certs in this p12 file.

Any ideas?


Shawn Beard • Sr. Systems Engineer
Middleware Engineering

[cid:image2958d0.PNG@871604a2.4590bc83]


 3840 109th Street Urbandale, IA 50322
 Phone: +1-515-564-2528
 Email: sbe...@wrberkley.com
 Website: 
berkleytechnologyservices.com

Technology Leadership Unleashing Business Potential



CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.

Re: SameSite cookies shows as "Unset" but Header shows Correct Value

[M. Manna]

Just to confirm, we know that Chrome will block JSESSIONID it if sent over
unsecure connection and with SameSite=None. But we saw the
previously mentioned issue in Firefox.

Thanks,

On Wed, 11 Mar 2020 at 15:33, M. Manna  wrote:

> Hi All,
>
> Due to the recent issues with Chrome 80, we have had to make some changes
> for our context.xml to have SameSite attribute setup for CookieProcessor
>
> What we've noticed is that even though CookieProcessorBase captures and
> assigns the correct value (e.g. "None" or "Lax"), the Network tab of
> browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if
> you observe the response header, it's actually setting the correct value.
>
> The question is - Would this be expected? Or, do we have to fix something
> here for browsers?
>
> Regards,
> M. MAnna
>

SameSite cookies shows as "Unset" but Header shows Correct Value

[M. Manna]

Hi All,

Due to the recent issues with Chrome 80, we have had to make some changes
for our context.xml to have SameSite attribute setup for CookieProcessor

What we've noticed is that even though CookieProcessorBase captures and
assigns the correct value (e.g. "None" or "Lax"), the Network tab of
browsers (e.g. Firefox, Chrome) always shows SameSite as "Unset". But if
you observe the response header, it's actually setting the correct value.

The question is - Would this be expected? Or, do we have to fix something
here for browsers?

Regards,
M. MAnna

Re: Novice Tomcat Admin Question - Filtering log output

[M. Manna]

Hey Darryl,

On Fri, 21 Feb 2020 at 17:15, Darryl Philip Baker <
darryl.ba...@northwestern.edu> wrote:

> I have taken over the administration of several Tomcat instances. A number
> of these are load balanced using an F5 appliance.  The
> org.apache.catalina.values.AccessLogValve log file is filled with the F5
> polls to see if the application is alive. Under almost all circumstances
> these are useless, I would like to stop logging just these requests. What
> is the best way to stop these entries being written?  I’ve included a
> sample of the log entries.
>
> 10.0.171.163 - - [21/Feb/2020:09:04:11 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.162 - - [21/Feb/2020:09:04:16 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.163 - - [21/Feb/2020:09:04:16 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.162 - - [21/Feb/2020:09:04:21 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.163 - - [21/Feb/2020:09:04:21 -0600] "GET /MySite/isAlive.jsp "
> 200 112
> 10.0.171.162 - - [21/Feb/2020:09:04:26 -0600] "GET /MySite/isAlive.jsp "
> 200 112
>
> The entry for the log file in server.xml is
>  directory="logs"
>prefix="localhost_access_log" suffix=".txt"
>pattern="%h %l %u %t %r %s %b" />
>
>
> Darryl Baker
> Northwestern University
> darryl.ba...@northwestern.edu
>

 I may be mistaken, but It seems you are probably trying to make the
logging coarser. You can take a look at conf/logging.properties for your
tomcat instances to do the adjustments of log levels.

Regards,

>
>

Re: cloud cluster

[M. Manna]

We are also using redis based option.

On Sun, 16 Feb 2020 at 17:32, Jonathan S. Fisher  wrote:

> We're doing the second: sessions stored in a Redis cluster with
> sticky sessions. This topology is simple and it scales pretty easily until
> it doesn't anymore [couple thousand simultaneous users]. You'll need to
> judiciously use your debugger and unix tools to find bottlenecks, as
> they're often hidden deep within the stack and present themselves in
> non-obvious ways. Important caveat: See the discussion from earlier this
> week on the mailing list about session replication and user authentication
> with the redisson session manager.
>
> On Sun, Feb 16, 2020 at 9:06 AM Jonathan Yom-Tov <
> jonathan.yom...@sysaid.com>
> wrote:
>
> > hi,
> >
> > What kind of configuration do people usually use when deploying on a
> public
> > cloud (e.g. AWS)? An auto-scaling cluster with session replication? A
> > auto-scaling cluster with all sessions stored in an external cache?
> >
> > Jon.
> >
>
>
> --
> Jonathan | exabr...@gmail.com
> Pessimists, see a jar as half empty. Optimists, in contrast, see it as half
> full.
> Engineers, of course, understand the glass is twice as big as it needs to
> be.
>

Re: Cross-session Persistent Object?

[M. Manna]

If database is the answer, you could use memcache/redis to do this too. It
should be able to support multiple servers if you need.

Since it’s only persistent based on tomcat, I was thinking at the servlet
context level only. Provided that database read overhead is acceptable,
it’s a more persistent solution.

Thanks,

On Tue, 11 Feb 2020 at 20:56, Rouse, Ed  wrote:

>
>
> From: Jerry Malcolm 
> Sent: Tuesday, February 11, 2020 3:12 PM
> To: users@tomcat.apache.org
> Subject: Cross-session Persistent Object?
>
> [External email: Use caution! Do not open attachments or click on links
> from unknown senders or unexpected emails.]
> I need some advice.  I need to maintain a set of long-running threads.
> When a request comes in, I need to determine if I have a thread started
> for a particular id found in the request.  So I need to have a hashmap
> of threads keyed by the ids.  That part is simple enough.  But I'm
> struggling with where to keep that hashmap object so that it is
> available to all incoming requests (any session).  This object should
> persistently remain as long as Tomcat is active.  It must be scoped to
> the virtual host and only needs to be available in one webapp context
> within that host. Suggestions on how to proceed will be greatly
> appreciated.
>
> Thx.
>
> Jerry
>
> I would set up a database table to store the values and create a
> class/script depending on your
> environment that would be able to do crud processes on the table. Maybe
> set it up as a web service
> if that would allow easier access for the individual webapps.
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org users-unsubscr...@tomcat.apache.org>
> For additional commands, e-mail: users-h...@tomcat.apache.org users-h...@tomcat.apache.org>
>

Re: Cross-session Persistent Object?

[M. Manna]

Jerry,


On Tue, 11 Feb 2020 at 20:12, Jerry Malcolm  wrote:

> I need some advice.  I need to maintain a set of long-running threads.
> When a request comes in, I need to determine if I have a thread started
> for a particular id found in the request.  So I need to have a hashmap
> of threads keyed by the ids.  That part is simple enough.  But I'm
> struggling with where to keep that hashmap object so that it is
> available to all incoming requests (any session).  This object should
> persistently remain as long as Tomcat is active.  It must be scoped to
> the virtual host and only needs to be available in one webapp context
> within that host. Suggestions on how to proceed will be greatly
> appreciated.
>
> Thx.
>
> Jerry
>
>  Would setting your hashmap as attribute to the Servlet context work?

>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 8.5.51/52 release time

[M. Manna]

Brilliant!.. Thanks Mark, helps a lot :)

On Tue, 11 Feb 2020 at 15:51, Mark Thomas  wrote:

> On 11/02/2020 15:44, M. Manna wrote:
> > Hello,
> >
> > Do we have any tentative timeline for next 8.5.x release ?
>
> The release vote for 8.5.51 passed earlier today. The formal
> announcement is expected tomorrow once the release has made it to most
> of the mirrors.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat 8.5.51/52 release time

[M. Manna]

Hello,

Do we have any tentative timeline for next 8.5.x release ?

Regards,

Question on HttpSession investigation

[M. Manna]

Hello,

I apologise in advance if the answer is obvious for this question. We are
trying to investigate (in an isolated cluster) whether our session
attributes are getting lost somewhere in the process.

The issue is that we are setting it at a JSP Tag Level, however, when we do
an AJAX request back to the same server, the session doesn't have the
attribute set by the tag. Since it's two different servers, we would like
to check using JMX whether this is present somewhere in session. Debugging
has not resulted into a successful outcome.

We appreciate if this is not possible, but just wanted to check if tomcat
currently emits anything related to this.

Regards,

Re: Class loader takes long time after server inactivity - Tomcat Version 9.0.10

[M. Manna]

Hey Niall,

On Tue, 14 Jan 2020 at 13:42, Niall Fitzpatrick 
wrote:

> Hi Folks,
>
>
>
> I have a web application that, after a period of inactivity (1-2hours),
> will stall for 3 – 35 seconds upon the first new session. All subsequent
> sessions will not experience this delay unless another period of inactivity
> occurs.
>
>
>
> I’ve found that the delay occurs when loading jars that live in the
> WEB-INF/lib folder.
>
>
>
> The issue doesn’t occur when the server is first started. Only after a
> period of 1-2 hours approx. will the next session experience the delay when
> loading a jar. This leads me to believe that when the server is started
> ‘knowledge’ of the jars might be cached, however, after a period of
> inactivity this cache may expire. The result of this is that the next
> session after this period causes the lib folder to be searched again which
> seems to take the 5-35 seconds.
>
>
>
> My question: Is this theory above correct, and if so, is there a way to
> configure Tomcat such that this cache doesn’t expire so that it doesn’t
> need to be re-populated when a new session begins?
>
>
>
> Tomcat Version 9.0.10
>
>
>
> Any help appreciated,
>
> Thanks,
>
> Niall
>

 Perhaps others can also correct me if i have missed - Tomcat does have a
resource caching and memory settings aka Resources:

https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html

That said, there is very small possibility (also partly coincidence) that
this is impacted by garbage collection cycles. We have got a production
scenario where garbage collection interfered with busy hour processing due
to having lower memory. But again, that's my own issue.
I think the link above may help you configure some things?

Regards,

Re: Possible release of next 8.5.x in 2020

[M. Manna]

Hey Mark,

On Mon, 13 Jan 2020 at 09:34, Mark Thomas  wrote:

> On 12/01/2020 21:03, M. Manna wrote:
>
> 
>
> > With regards to my enquiry, I’m simply trying to find out whether there
> > would be a new release coming out this January 2020.
>
> I am currently aiming to make 9.0.x and 8.5.x releases (and possibly
> 10.0.0.Mx depending how things go) early in February.


 Thanks a bunch. We will keep an eye out.

Regards,

>
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Possible release of next 8.5.x in 2020

[M. Manna]

He Michael,

On Sun, 12 Jan 2020 at 20:55, Michael Osipov  wrote:

> Am 2020-01-12 um 19:26 schrieb M. Manna:
> > Hey All,
> >
> > Just trying to get a timeline (or possible release time) for next 8.5.x.
> > The latest release is 8.5.50 from December 2020. I am assuming there is
> one
> > imminent for January 2020?
> >
> > This is purely for individual interest as my dev cycle requires a tomcat
> > upgrade 4 times a year.
>
> This might be wrong because you could miss important releases with
> security fixes or else.


 We operate under strict SLAs and every tomcat upgrade requires a full
regression cycle for our product due to the nature of integration. And we
only have 4 such slots per year to do it. Also, not all CVEs are relevant
to what/how we use tomcat.

With regards to my enquiry, I’m simply trying to find out whether there
would be a new release coming out this January 2020.

>
>

Possible release of next 8.5.x in 2020

[M. Manna]

Hey All,

Just trying to get a timeline (or possible release time) for next 8.5.x.
The latest release is 8.5.50 from December 2020. I am assuming there is one
imminent for January 2020?

This is purely for individual interest as my dev cycle requires a tomcat
upgrade 4 times a year.

Regards,
M. MAnna

Re: Dates on Linux vs. Windows

[Terence M. Bandoian]

On 1/7/2020 6:53 PM, Jerry Malcolm wrote:
>> If your systems always use the same time zone to read and write the 
data, it isn't a problem.


Terrance, thanks for the info.  In my case I do only have one timezone 
(or at least I want to...).  Using the string for dates is a good 
idea.  But this is a massive application that's been in production for 
years with tons of date and timestamp fields spread everywhere across 
the code and the db.  So converting to strings is not a possibility now.


It still comes down to the fact that the mysql command line on my 
linux box gets the date right, but it's converted incorrectly by JDBC 
and only on the linux box (and works on WIndows)


When I first set up the box an installed Tomcat, the default Linux 
time was gmt.  I didn't change the Linux time to central until later.  
Any chance that tomcat stored the timezone in effect when it was 
installed and still is using that even though I changed the linux 
timezone?  (Just grasping at straws here).





Hi, Jerry-

I realize you've found an apparent work-around for the issue but, to be 
clear, I did not use character columns.  The column types were 
DATETIME.  However, when I inserted or updated, I provided string values 
(e.g. update MyTable set myDateTime = '2020-01-08 06:57:00').  And, when 
I read the data, I extracted date/time values from the result set using 
getString (e.g. parseSqlDateTime( resultSet.getString( "myDateTime" ) ).


Best regards.

-Terence Bandoian

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Dates on Linux vs. Windows

[Terence M. Bandoian]

On 1/7/2020 4:04 PM, Zahid Rahman wrote:

  Jerry Malcolm wrote :

  >Again this is the SAME line of code in java reading the   >SAME field in

the SAME database.  Only thing different is  >Linux/Windows OS




On Tue, 7 Jan 2020, 21:52 ,  wrote:


-Original Message-
From: Jerry Malcolm 
Sent: Tuesday, January 07, 2020 3:14 PM
To: users@tomcat.apache.org
Subject: Re: Dates on Linux vs. Windows

On 1/7/2020 3:09 PM, Michael Osipov wrote:

Am 2020-01-07 um 21:58 schrieb Jerry Malcolm:

This may be more of a Java question than Tomcat.  But I'm not sure. I
have the same code, talking to the same MySql Linux (AWS) database.
I read a date column value in a Tomcat app.  After calling
resultSet.getDate(...) I printed the date instance and the getTime()
value:

On windows: 2019-02-01 154900080

On linux:   2019-01-31 154897920

Again this is the SAME line of code in java reading the SAME field in
the SAME database.  Only thing different is Linux/Windows OS.  The
date is supposed to be 2/1/2019 and shows that in phpMyAdmin.

I've been running on Linux for a few months.  But I don't have an
extensive background in the specifics of Linux.  I'm sure there must
be something that is configured differently.  I'm at a loss. But this
is not a trivial problem.  I do monthly billing. My dates need to be
accurate.

Have you verified that you aren't tricked by any timezone issues?

Probably so.  But how would I know?  I was under the impression that
java.sql.Date was timezone independent.  Shouldn't it simply convert a
month/day/year value to the number of milliseconds since the epoch?  How
would timezone issues affect that?  And if I am 'tricked' how do I
'untrick'.  What do I set/change?



Those millisecond values are 6 hours apart, which looks like a timezone
issue.  I happen to be in US Central time, which is 6 hours earlier than
UTC in winter.

You're right that System.currentTimeMillis() itself is independent of
timezone but Date is not.


As I understand it, for certain date/time column types, MySQL subtracts 
the time zone from the value when written and adds it back in when 
read.  If your systems always use the same time zone to read and write 
the data, it isn't a problem.  But it can be if the time zone varies.


See https://dev.mysql.com/doc/refman/5.7/en/datetime.html

The actual behavior is a little confusing, at least to me, because I 
seem to remember variations in the storage of the date/time columns 
while the documentation seems to indicate that date/time values are not 
modified.  Also, if I remember correctly, writing a date/time value as a 
formatted string and then reading it back as a string (e.g. 
ResultSet.getString) and parsing it circumvented the time zone issue.


Hope that helps.

-Terence Bandoian


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: HTTP/2 configuration

[M. Manna]

Hey Mark et. al.,

On Tue, 7 Jan 2020 at 11:20, Mark Thomas  wrote:

> On 12/12/2019 15:23, Christopher Schultz wrote:
> > Arief,
> >
> > On 12/12/19 00:25, Arief Hasani wrote:
> >> IMHO, being able to override form HTTP1.1 conf is all good as user
> >> could easily assume that if not specified in the upgrade than use
> >> http1.1 configs
> > I'm not sure you understand the question.
> >
> > Mark is asking if any users in the community are finding that they
> > need to independently configure specific parts of the HTTP/<2 versus
> > h2 *for the same port*.
> >
> > Thinks like the compression, keepalives, max headers/trailers,
> > timeouts, sendfile config, etc.
> >
> > Does it ever make sense to have sendFile enabled on the HTTP/1.1
> > connector but disable sendFile if the client upgrades to h2?
>
> Exactly.
>
> > The suspicion is that identical configuration is acceptable. Mark is
> > trying to ask if there are any exceptions before we simplify the code
> > which handles the configuration.
> >
> > If you have a specific use-case, please explain.
>
> Just pinging this thread in case there is someone with a specific use case.
>
> At the moment, I'm leaning towards the simplification for Tomcat 10
> onwards.
>

 It's probably better that way. The change here is big and a major release
such as 10.x is more appropriate for GA.


> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 does not allow to read file in /tmp folder with 777 permission?

[M. Manna]

Hi,

On Sat, 4 Jan 2020 at 14:36, bphamhuu  wrote:

> Hello,
>
> I have a java web application by Tomcat 9 servlet container which tries to
> read a file in /tmp folder with 777 permission on Ubuntu 18.04
>
> ls -ltr /tmp/test.txt
> -rwxrwxrwx 1 vagrant vagrant 10 Jan  3 17:03 /tmp/test.txt
>
> The java code is:
>
> try {
> result = FileUtils.readFileToString(new File("/tmp/test.txt"));
> } catch (IOException ex) {
> log.info("# Cannot read file. Reason: " + ex.getMessage());
> }
>
> But it always show the error
>
> # Cannot read file. Reason: File '/tmp/test.txt' does not exist
>
> This test file can be opened fine by a normal user on a terminal window
> (example user: vagrant).
>
> vagrant@ras:~$ cat /tmp/test.txt
> asdasdsad
>
> Does anybody know about the problem with Tomcat 9? I'll need the java web
> application to read this test file as string.
>
> Thanks,
>
>
>   What is the full stack trace?

>
> --
> Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Hide a request header to application

[M. Manna]

Oliver,

On Mon, 16 Dec 2019 at 11:09, Olivier Jaquemet 
wrote:

> Hello all,
>
> I would like to systematically hide a request header to web applications
> hosted by Tomcat.
>
>   "Blanking" or "Unsetting" a header is not the same as "Hiding". By
hiding, you are essentially asking for the Header to be available under
certain elevated privilege or conditions. Unless, you meant Unsetting the
value or removing the header (not "Hiding")?

> - If Apache HTTPD is used in front of Tomcat, you can use the
> RequestHeader directive [0]:
> RequestHeader unset Some-Header-Name
>
> - If NGINX is used in front of Tomcat, you can use the proxy_set_header
> directive [1]:
> proxy_set_header Some-Header-Name "";
>
> - Is there any way to apply a similar configuration (no development [2])
> to Apache Tomcat when there is no front server ?
> I could not find any built-in valve/filter that would allow such
> filtering. I don't think there is any, but I wanted to make sure I had
> not missed something.
>
>  Not to my knowledge. But I don't see why you cannot implement your own
Valve. Of course, any suggestion is welcome unless someone else has any
other suggestions?



> Olivier
>
> [0]
> https://httpd.apache.org/docs/current/mod/mod_headers.html#requestheader
> [1]
> http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
> [2] I know it is possible to develop a quite simple custom ServletFilter
> to wrap the request with a custom HttpServletRequest wrapper, but I'm
> looking for a zero development possibility. For those of your reading
> this discussion later and looking for a development solution, you can
> find inspiration in the following github repo that you can adapt to
> handle removal
> https://github.com/lonelyplanet/tomcat-request-header-filter
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: HTTP/2 configuration

[M. Manna]

Mark,

On Wed, 11 Dec 2019 at 11:48, Mark Thomas  wrote:

> All,
>
> The Tomcat committers are looking for some user feedback.
>
> Currently, the HTTP/2 protocol configuration [1] duplicates many
> attributes of the HTTP/1.1 protocol [2] it is nested under.
>
> We are considering simplifying this for Tomcat 10 onwards and having the
> HTTP/2 protocol simply inherit the settings from HTTP/1.1. Optionally,
> we could have HTTP/2 inherit from HTTP/1.1 by default but allow an
> HTTP/2 specific override if required. However, this adds quite a few
> edge cases and I can't think of a use case where, for example, you'd
> want to have different maxHeaderCount settings on HTTP/1.1 and HTTP/2.
>
>  Inheritance seems to be an easier choice. Would this mean various
connectors
might then be using a "Factory"-like (insted of specific Http11*Protocol)
to refer to the correct underlying protocol?

> So, users, what do you think?
>
> Mark
>
>
>
> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/http2.html
> [2] http://tomcat.apache.org/tomcat-9.0-doc/config/http.html
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Design Patterns in Tomcat

[M. Manna]

Chris,

On Mon, 9 Dec 2019 at 17:10, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> M,
>
> On 12/8/19 17:10, M. Manna wrote:
> > Hi All,
> >
> > A numpty question as its best, but I was trying to summarise the
> > design patterns used for tomcat. So far I could see the following,
> > but shouldn't be limited to:
> >
> > 1) Mediator 2) Observer 3) Factory 4) Builder 4) Adapter
> >
> > Perhaps I missed any confluence link or something that confirms
> > it?
>
> Don't forget iterator, interceptor, etc.
>
> We don't bother to track which design patterns are in use in Tomcat.
> Some of them are obvious due to their class names or behavior, but
> there is no documentation about what is being used where.
>
> There is also the problem of having a very large number of named
> design patterns, many of which are variations on a theme. You may see
> code that looks like publish/subscribe and others may call that
> observer/observable, etc. Some patterns are so obvious as to not
> require naming at all (e.g. "State").
>
> If you'd like to hunt through the code and find examples of carious
> patterns and document them -- e.g. in the Wiki -- that would be fine,
> but I don't think any committer is currently interested in such a task.

i guess it’s more or less what I was sexpecting. Let me work on the page
and perhaps I wi also provide 1/2 examples to support it. As long as folks
keep it correct, it should be a good source.

Thanks,

>
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3uf/oACgkQHPApP6U8
> pFgieQ/+LSNxlzLoM8XBtE/sNQlM+HXokdAAenakQb7jGHzKYGo7ElBL3+o0FORg
> /4HRQYO7sO9PkWDmBY8oAlxlXPdCwx6KSkK2ZFMi8kW4cOabqLXl0l7KpOI2TGNK
> u7aq7jJxN8k/OmcBdlIutYpKScB//kp9wDei6G2lEGdoQh2qMMgsWN7q9J9IGAO2
> CTB3JMVTy2LQGbXSPBGhNgRhpL4DykoHqpLCflsA9rhPGFVnN+cnCsFmiI3XREHD
> N/ap5ffXA2yOeOIuR5vhBolQJ2/3bGOQdIUrliGXMEv2hefslP+fQYudOAYzapju
> MO5VBVwOhtL0cZlVdOAgMJRL4V/Y91rSIXIS1gw/RKGV5cdEl+6VoyQhEVmRQa6u
> gHQ2HWrT+MyAV72YBulalPJy3c1vlr3Lna5kJFsxWB9rwdGZLv2xWIrWmINecdI1
> GAadRCzI0QOPA1leoq0ZdjtLvuk3W0m9+98V/uy9nrz6eyZ2hm2dFoTRvM2bbLda
> +aSwQssfaiq3QyoOxOmpeb3tWzQMXHeeoq6u5tnCwktNXUV78ZE4q6IiU9wcW8/L
> Z1/0VwhEWTF/cP8MSnqhMquEYoFVnFv2HBRE8eYIshKw2KrnlIzjYwGHCYqjRTNK
> DNSYvvuzf7s5pdzG7EtrrvOVNW7mH5Qtvs2hx1C55BijJRf3Rx0=
> =aczA
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Tomcat is throwing an error Invalid byte tag in constant pool:19

[Nelligan, Steven M]

Thank you for your response...

We run multiple servers for our application.

We have a configuration as follows:
1. Portal ... running tomcat 7.0_45 and java 7... this is the outward 
facing running jetspeed.  This is the server throwing the errors
2. Tomcat ... running tomcat 7.0_45 and java 7... this is our back-end 
business logic server
3. Mule .. enterprise service bus broker ... no tomcat running java 7
4. AiM .. our ERP software from a third party  ... runing tomcat_9 and 
java 11

We cannot upgrade Java at this point, because of an old third party application 
running on the portal.  It requires Java 7.  
We are currently exploring new packages to replace it, but this will take some 
time to finalize.

I've attached the catalina log showing the error.  The error appears on startup 
of Tomcat.

I tried to replace the annotation_api.jar with a newer version, somewhere on 
the web, it was posted that replacing this jar file with a new version solved 
his problem; which was simular to mine.

Steve

-Original Message-
From: Mark Thomas  
Sent: Monday, December 9, 2019 5:17 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat is throwing an error Invalid byte tag in constant pool:19

On 09/12/2019 00:57, Nelligan, Steven M wrote:
> 
> I am trying to rebuild my applications and all of a sudden, I am getting the 
> following error:
> 
> Our backend application (from third party has been updated) It is using Java 
> 11.

You'll need at least 7.0.88 for Java 11 support.

> When I first tried this a couple of weeks ago... I needed up trying to 
> upgrade Tomcat to the latest release of 7.0_94

That is what I would recommend (or latest 8.5.x / 9.0.x but that is probably 
changing too much in one go).

> Everything started to fall apart, the javax modules were failing, etc.  I 
> finally realized I was chasing my tail.
> Every time I got one thing working, two more broke.
> 
> Restored everything back and went through the rebuild.

You are going to have to try this again. Can I suggest you post the first error 
you see here and we can try and talk you through fixing it.

> I tried to copy the annotation_api.jar file from Tomcat 7.0_94 into tomcat 
> 7.0_45 but nothing would deploy...

Why do that?

Mark

-
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

Tomcat is throwing an error Invalid byte tag in constant pool:19

[Nelligan, Steven M]

I am trying to rebuild my applications and all of a sudden, I am getting the 
following error:

Our backend application (from third party has been updated) It is using Java 11.

My tomcat servers are running version 7.34 of tomcat and version 1.7.0_45.

I have rebuilt and deploy a large number of our Apps; but there are about 4 
with the following error:
SEVERE: Unable to process Jar entry [module-info.class] from Jar 
[jar:file:/G:/Tomcat7/temp/44-bannertools/WEB-INF/lib/jaxb-api-2.3.0.jar!/] for 
SEVERE: Unable to process Jar entry [module-info.class] from Jar 
[jar:file:/G:/Tomcat7/temp/44-bannertools/WEB-INF/lib/jaxb-api-2.3.0.jar!/] for 
annotations
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in 
constant pool: 19
at 
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:133)
at 
org.apache.tomcat.util.bcel.classfile.ConstantPool.(ConstantPool.java:60)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2104)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1980)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1946)
at 
org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1931)
at 
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1325)
at 
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977)
at 
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655)
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)
s
org.apache.tomcat.util.bcel.classfile.ClassFormatException: Invalid byte tag in 
constant pool: 19
at 
org.apache.tomcat.util.bcel.classfile.Constant.readConstant(Constant.java:133)
at 
org.apache.tomcat.util.bcel.classfile.ConstantPool.(ConstantPool.java:60)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.readConstantPool(ClassParser.java:209)
at 
org.apache.tomcat.util.bcel.classfile.ClassParser.parse(ClassParser.java:119)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:2104)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1980)
at 
org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1946)
at 
org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1931)
at 
org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1325)
at 
org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:369)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at 
org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
at 
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5173)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977)
at 
org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655)
at 

Design Patterns in Tomcat

[M. Manna]

Hi All,

A numpty question as its best, but I was trying to summarise the design
patterns used for tomcat. So far I could see the following, but shouldn't
be limited to:

1) Mediator
2) Observer
3) Factory
4) Builder
4) Adapter

Perhaps I missed any confluence link or something that confirms it?

Thanks,

Re: Unknown protocol: e on Windows

[M. Manna]

Chris,

On Wed, 4 Dec 2019 at 18:34, Konstantin Kolinko 
wrote:

> ср, 4 дек. 2019 г. в 20:28, Christopher Schultz <
> ch...@christopherschultz.net>:
> >
> > All,
> >
> > I feel like I should be able to figure this out on my own, but I'm
> > drawing a blank.
> >
> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> > 8.5.35 and I'm getting errors on a certain portion of the
> > conf/server.xml configuration.
> >
> > I copy have a perfect copy/paste of the config file here but basically
> > this is configuring a keystore for TLS. Something like this:
> >
> >  > keystoreFile="E:\path\to\keystore.jks"
> > [...]
> > />
> >
> > The error is "unknown protocol: e". Clearly, Tomcat/Java/URL/whatever
> > thinks that "E:" is a protocol. No problem... this has to be a file
> > URL, so let's make it a file URL: [...]
>
> Chris,
>
> 1) Do know where that message is produced? (Stacktrace? What version of
> Tomcat?)
>
> E.g. it may be that the code has several attempts to use the value a)
> as file path, b) as URL,  and you only see the message from the second
> attempt b), but it is a) that fails.
>
> Is your keystoreFile path correct?
>
> 2) Why the settings are specified on a . They will be
> translated into / on the fly, but maybe
> something is broken.
>
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/http.html#SSL_Support_-_Certificate
> It says that certificateKeystoreFile can be an URI.
>
> 3) Does you connector use JSSE or OpenSSL?
>
> There is some code that translates between the two configuration
> flavors on the fly, but maybe something is broken.
>
> > I'm using Oracle Java 1.8.0 build 161.
>
> FYI, an up-to-date version of Java 8 for Windows is available from
> AdoptOpenJDK.
> https://adoptopenjdk.net/
>
> It is 8u232 now.
>
> Best regards,
> Konstantin Kolinko
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
I have just launched tomcat 8.5.47 stockpile with the following connector
config (i generated keystore Jeeks before)



And my tomcat cert gen command was:

>keytool -genkeypair -alias tomcat -keyalg RSA -keystore tomcat.jks
-keypass changeit -storepass changeit

It only gave me warning about non-legit cert when I hit
https://localhost:8443 but that's expected. Otherwise, no errors.

I suspect your E:\ drive is a network drive (or virtual) so the mapping may
be causing issues ? Or may be it's the partitioning...?

Re: Unknown protocol: e on Windows

[M. Manna]

Also, with Windows \\ escape often has the tricks.

On Wed, 4 Dec 2019 at 17:43, M. Manna  wrote:

> Chris,
>
> On Wed, 4 Dec 2019 at 17:38, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> All,
>>
>> I should note that I'm using Oracle Java 1.8.0 build 161.
>>
>> I have seen another environment with essentially the same
>> configuration that seems to work. The path is
>> "E:\path\to\keystore.jks" and there are no errors.
>>
>> Thanks,
>> - -chris
>>
>> On 12/4/19 12:27, Christopher Schultz wrote:
>> > All,
>> >
>> > I feel like I should be able to figure this out on my own, but I'm
>> > drawing a blank.
>> >
>> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
>> > 8.5.35 and I'm getting errors on a certain portion of the
>> > conf/server.xml configuration.
>> >
>> > I copy have a perfect copy/paste of the config file here but
>> > basically this is configuring a keystore for TLS. Something like
>> > this:
>> >
>> > 
>> >
>> > The error is "unknown protocol: e". Clearly,
>> > Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
>> > problem... this has to be a file URL, so let's make it a file URL:
>> >
>> > > > [...] />
>> >
>> > Same error.
>> >
>> > What if I remove the drive letter?
>> >
>> > > > />
>> >
>> > Same error (including the "e"!).
>> >
>> > Okay, maybe e:/ looks like a protocol. How about using
>> > backslashes?
>> >
>> > > > [...] />
>> >
>> > "Illegal character in path" :(
>> >
>> > What's the right way to write a Windows path containing a drive
>> > letter?
>> >
>> > -chris
>> >
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
>> pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
>> 9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
>> bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
>> g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
>> 65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
>> GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
>> cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
>> HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
>> fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
>> rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
>> 0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
>> =gJWI
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>> Have you tried E:/path/to/cert.jks ?
>

Re: Unknown protocol: e on Windows

[M. Manna]

Chris,

On Wed, 4 Dec 2019 at 17:38, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I should note that I'm using Oracle Java 1.8.0 build 161.
>
> I have seen another environment with essentially the same
> configuration that seems to work. The path is
> "E:\path\to\keystore.jks" and there are no errors.
>
> Thanks,
> - -chris
>
> On 12/4/19 12:27, Christopher Schultz wrote:
> > All,
> >
> > I feel like I should be able to figure this out on my own, but I'm
> > drawing a blank.
> >
> > I'm trying to upgrade from Apache Tomcat 8.0.35 to Apache Tomcat
> > 8.5.35 and I'm getting errors on a certain portion of the
> > conf/server.xml configuration.
> >
> > I copy have a perfect copy/paste of the config file here but
> > basically this is configuring a keystore for TLS. Something like
> > this:
> >
> > 
> >
> > The error is "unknown protocol: e". Clearly,
> > Tomcat/Java/URL/whatever thinks that "E:" is a protocol. No
> > problem... this has to be a file URL, so let's make it a file URL:
> >
> >  > [...] />
> >
> > Same error.
> >
> > What if I remove the drive letter?
> >
> >  > />
> >
> > Same error (including the "e"!).
> >
> > Okay, maybe e:/ looks like a protocol. How about using
> > backslashes?
> >
> >  > [...] />
> >
> > "Illegal character in path" :(
> >
> > What's the right way to write a Windows path containing a drive
> > letter?
> >
> > -chris
> >
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3n7xcACgkQHPApP6U8
> pFiz3Q/+L85HlQ1s6O+Wz0kmrp3FhsuTQNizoAnEQL7lvXd+AGi2sAIagRyTfme1
> 9MsWYBLYk0pTnOS+1mAnSt6FNNRKjdoJ0ud/rCXblqIwWX3j3nS1jifx92mQDQWt
> bHISBL9wORBxaS+ENE1kicSBsVAJvEBA8gAY9p5kYncL9K1tK54XoklujTIHxrfU
> g0NdprFv1LYZxxQyWmoP5zHSfvBsR2pjLpLSn3G2q32+gALgfu5hAWuJIUq5z4XZ
> 65sfVEtfV9lntohTNqWqu5tdrg0TyblXMruNMB9ygW2DAbHO93Sjkpj2t/AieQwv
> GtvJd1XC7shERazFtplE6o5UZaOrg+N/B2BALvqVoVMR+tAGNrbQqZZjDz+zPzGA
> cL3xNcKN5OqPMFbnge8Ar1v87ywcmvO3arj1lvE6kt97VNeSAOFj7+9i2VWEqu0K
> HDrLv4Ca2ESu3k/MO/eerC5os2dEoVXQEejyBrMtHPDaD40VxJIrYbRmbS/dqk5F
> fjSmcWIopl3+z8/6lex2JGNc26liyvseIrnUtCP8CUklDMilS2XOGVvypDmZNEH1
> rce8IBV3LrRqO/VJ18/VWsc6u6qp9QB6bD8Qvo/dpvX3uIeb4QDDz/9W1UDibG37
> 0ZBqHkjty8C5wHxf5ep06lSdLbiH2NdY1LXKkz5Ru9cXElifVaE=
> =gJWI
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> Have you tried E:/path/to/cert.jks ?

Re: [E] Global Error Handling

[Bauer, Margaret M (Peggy)]

I think you can add your customized jsp page within your web.xml by
modifying path and file name

 
401
/WEB-INF/jsp/401.jsp
  
  
403
/WEB-INF/jsp/403.jsp
  
  
404
/WEB-INF/jsp/404.jsp
  

On Tue, Dec 3, 2019 at 8:11 AM Sumit Bhardwaj 
wrote:

> Hi Experts,
>
> We have a requirement from a customer, where in case of 404, where someone
> is putting an invalid url, instead of showing the default error, we should
> be showing a custom message.
>
> Is this possible?
>
> I have searched and found couple of solutions similar to
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com_questions_27859626_tomcat-2Dserver-2Dchange-2Ddefault-2Dhttp-2D404=DwIBaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=JYuCIQ8r7H-c_yYFTZ4gdv4goO0lCCtidMRmNza4zoA=W70UQy0yQZ6RcqlHmp6JmY1-JKse-vhMHnH9vleLY7o=rhOgsU2tAGMdFGQL-8RDhOtdkd11pYl5mOR1R4rQNKI=
>
>
> but these did not work, these work at the app level, but not globally on
> tomcat level.
>
> e.g. if i have an app called myapp
>
> http:///myapp/ This  works and it gets
> redirected to custom page
>
> but
>
> http:///, This does not work and 404 is
> shown,
>
> Is there someway we can handle errors at global level on tomca.t
>
> We are using tomcat 9.0.24.
>
> Thanks for your help.
>
> Best
> Sumit Bhardwaj
>


-- 
*Peggy Bauer*
CAO Production Support
214-770-1782

Re: SEVERE: A child container failed during start

[M. Manna]

Karen,

On Sat, 30 Nov 2019 at 00:58, Karen Goh 
wrote:

>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Saturday, November 30, 2019, 6:18 AM, Mark Thomas 
> wrote:
>
> On 29/11/2019 21:28, Karen Goh wrote:
> > I have done so but it is no use. I have deleted the Tomcat and add an
> new instance before run the server again.
> > caused by java.lang.IllegalArgumentException : Filter mapping specifies
> an unknown filter name[SessionValidator]
> > Sorry I am having problem with writing here using Yahoo mail n I have to
> type things out in iPhone so I can’t copy n paste the entire error
> message. Should you need more info in order to help me I hope I can just
> write above the reply message.
>
> You seem to be missing the point. The problematic filter is named:
>
> httpHeaderSecurity
>
> You need to find where that is referenced in your code and/or
> configuration.
> I can’t find this filter at all, even though I am playing with something
> along the line of httpHeaderSecurity (JWT/JSSE etc to be precise) but my
> project is done intermittently cos most of the time I am meshing up the
> code from various sources and use it...
> What do I do in this case?  Re-start a fresh project?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
As I replied before, your best option would be:

1) remove all your custom filters from filter mappings so that there is no
filter (only for this test).
2) Start tomcat and confirm that startup is normal without issues
3) Now put back your filters 1-by-1 and repeat step 1-2 to see what breaks.

It's appears a big effort at first glance, but it's a good way to sift
through the problem.

Thanks,

Re: SEVERE: A child container failed during start

[M. Manna]

Karen,

On Fri, 29 Nov 2019 at 20:51, Karen Goh 
wrote:

>
>
>
> Sent from Yahoo Mail for iPhone
>
>
> On Friday, November 29, 2019, 8:39 PM, Karen Goh
>  wrote:
>
>
>
>
>
>
> On Friday, November 29, 2019, 6:59:38 PM GMT+8, Mark Thomas <
> ma...@apache.org> wrote:
>
>
> On 29/11/2019 10:44, Karen Goh wrote:
> > Hi experts,
> >
> >
> > Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27. Windows OS. Eclipse 2019-09.
> >
> > Have been trying to tackling the problem with no avail.
> >
> > Would appreciate some tips on how to make these error go away.
>
> 
>
> > Caused by: java.lang.IllegalArgumentException: Filter mapping specifies
> an unknown filter name [httpHeaderSecurity]
>
> 
> I am not sure why the error persists even if I change the filter mapping
> to :
>
> SessionValidator/login.jsp
> And here is snippet my Filter :
> @WebFilter(“/SessionValidator”)public class SessionValidator implements
> Filter
> public void doFilter(ServletRequest request, ServletResponse response,
> FilterChain chain) throws IOException, ServletException{
> ..HttpSession session = httpRequest.getSession();If(session.isNew())
> {httpResponse.sendRedirect(httpResponse.encodedRedirectURL(httpRequest.getContextPath()
> + “/login.jsp”return;}And then redirect the user to error.html if log in
> user is null.
> Please let me know what’s wrong.
> Thanks
> Where and how is this filter specified as being required?
> Where and how is this filter defined?
>
> Please see below
>
> 
> http://www.w3.org/2001/XMLSchema-instance; xmlns="
> http://xmlns.jcp.org/xml/ns/javaee; xsi:schemaLocation="
> http://xmlns.jcp.org/xml/ns/javaee
> http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd; version="4.0">
>  Archetype Created Web Application
>  
>  
>  Restricted Area
>  /search.jsp
>  
>  
>  
>  SessionValidator
>  Controller.SessionValidator
>  
>  
>  404
>  /error.html
>  
>  
>  403
>  /error.html
>  
>  
>  500
>  /error.html
>  
>  
>  java.lang.Exception
>  /error.html
>  
> 
>
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
>
>
>
 I would advise that you remove @WebFilter and try again. Seems like it's
conflicted with processing annotation based and web.xml supplied filter
definitions.
Once you remove the annotation, give it a try and let us know.

Thanks,

Re: Tomcat 9 relaxedQueryChars format

[M. Manna]

To clarify (along with my last reply) - what you are trying to do is not
correct. The tomcat documentation confirms that only the following are
allowed

The HTTP/1.1 specification <https://tools.ietf.org/rfc/rfc7230.txt> requires
> that certain characters are %nn encoded when used in URI query strings.
> Unfortunately, many user agents including all the major browsers are not
> compliant with this specification and use these characters in unencoded
> form. To prevent Tomcat rejecting such requests, this attribute may be used
> to specify the additional characters to allow. If not specified, no
> additional characters will be allowed. The value may be any combination of
> the following characters: " < > [ \ ] ^ ` { | } . Any other characters
> present in the value will be ignored.


On Fri, 29 Nov 2019 at 15:39, M. Manna  wrote:

> Robert,
>
> On Fri, 29 Nov 2019 at 15:28, Robert Hicks  wrote:
>
>> What is the correct format?
>>
>> I see the following used when I do a search:
>>
>> relaxedQueryChars="[,],{,}.|"
>>
>> relaxedQueryChars="[ ] { } |"
>>
>> relaxedQueryChars="[]|{}^"
>>
>> We use that last one. I am running down this error:
>>
>> java.lang.IllegalArgumentException: Invalid character found in the
>> request target. The valid characters are defined in RFC 7230 and RFC
>> 3986
>>
>> Thanks!
>>
>> --
>>
>>
> This is a working version in Http11AprProtocol
>
> relaxedQueryChars="{[,:]|}"
>
>
>
>
>> Bob
>>
>

Re: Tomcat 9 relaxedQueryChars format

[M. Manna]

Robert,

On Fri, 29 Nov 2019 at 15:28, Robert Hicks  wrote:

> What is the correct format?
>
> I see the following used when I do a search:
>
> relaxedQueryChars="[,],{,}.|"
>
> relaxedQueryChars="[ ] { } |"
>
> relaxedQueryChars="[]|{}^"
>
> We use that last one. I am running down this error:
>
> java.lang.IllegalArgumentException: Invalid character found in the
> request target. The valid characters are defined in RFC 7230 and RFC
> 3986
>
> Thanks!
>
> --
>
>
This is a working version in Http11AprProtocol

relaxedQueryChars="{[,:]|}"




> Bob
>

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

Kushagra,

On Fri, 29 Nov 2019 at 12:29, Kushagra Bindal 
wrote:

> Hi Mark,
>
> This astrik is because I highlighted it as BOLD. But I guess at your end it
> is being received as plain text. Resending the content in context.xml
>
> 
>
> 
> 
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
>  type="javax.sql.DataSource"/>
>
>  className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
> 
> 
>
> 
> 
> 
>
>
>
> On Fri, Nov 29, 2019 at 5:52 PM M. Manna  wrote:
>
> > Hi
> >
> > On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal  >
> > wrote:
> >
> > > Hi Mark,
> > >
> > > We tried to put the changes as suggested by you. Below are the changes
> > that
> > > we have made in context.xml file.
> > >
> > > 
> >
> >
> > Why this asterisk? *
> >
> > >
> > >
> > > 
> > > 
> > > WEB-INF/web.xml
> > > WEB-INF/tomcat-web.xml
> > > ${catalina.base}/conf/web.xml
> > >
> > >  > > type="javax.sql.DataSource"/>
> > >
> > >  > > className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
> > >
> > > 
> > > 
> > >
> > > 
> > > 
> > > 
> > >
> > > But after restart still I am getting below errors in tomcat's
> > > *localhost_access_log.2019-11-29.txt* file.
> > >
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > > 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> > > /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> > >
> > > Please help me in correcting the syntax.
> > >
> > > Regards
> > > Kushagra
> > >
> > > On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal <
> > bindal.kusha...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi Mark,
> > > >
> > > > Thanks for providing the response.
> > > >
> > > > Yes, you are right that we should design our application to remove //
> > > from
> > > > being used.
> > > >
> > > > I will plan it accordingly, for the provided solution in below. Let
> me
> > > try
> > > > the same and I will revert back to you in case of any further queries
> > and
> > > > concerns.
> > > >
> > > > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> > > >
> > > >> HI,
> > > >>
> > > >>
> > > >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> > > bindal.kusha...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > We are working on upgrading our enterprise application from 8.5.24
> > to
> > > >> > 9.0.27 version.
> > > >> >
> > > >> > What we have observed that in earlier version i.e. 8.5.24 we were
> > able
> > > >> to
> > > >> > process process a REST URI have  double slash ("//") in it.
> > > >> >
> > > >> > But when we are upgrading it to 9.0.27 we found that now the same
> > url
> > > >> which
> > > >> > was working earlier it is now throwing 404 status code.
> > > >> >
> > > >> > Now, the problem is that we can not remove these double slash (//)
> > > >> manually
> > > >> > as it is used widely.
> > > >> >
> > > >> > So, can someone please provide a possible solution of this issue?
> > > >> >
> > > >>
> > > >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> > > >> multiple
> > > >> leading forward slash support was disabled by default for good
> > reasons.
> > > >> This was done in 8.5.31 due to issues with Http Redirects involving
> > > >> Servlets.
> > > >>
> > > >> If you must use this, you have to modify your application context to
> > add
> > > >> the override as true - the attribute is called
> > > >> "allowMultipleLeadingForwardSlashInPath".
> > > >>
> > > >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> > > >>
> > > >> But I would sincerely recommend that you work on such designs and
> > > correct
> > > >> them in your application. There is always a "way". This is one of
> the
> > > >> reasons web applications become obsolete requires huge maintenance.
> > > >>
> > > >> Thanks,
> > > >>
> > > >> >
> > > >> > --
> > > >> > Regards,
> > > >> > Kushagra Bindal
> > > >> > +91-9013792807
> > > >> >
> > > >>
> > > >
> > > >
> > > > --
> > > > Regards,
> > > > Kushagra Bindal
> > > > +91-9013792807
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Kushagra Bindal
> > > +91-9013792807
> > >
> >
>
>
I have just started a tomcat with


in the context.xml file. works just fine. I am not Mark, but he did suggest
that your issue is probably handled better in filtering at Servlet request
level.

If you also provide the below (as Mark suggested earlier in his reply),
that will be great:


>
>
>
> *Can you provide more details such as:- an example request URI- the
>  for the servlet you expect it to match toThanks,Mark  *


Thanks,



> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

Hi

On Fri, 29 Nov 2019 at 11:43, Kushagra Bindal 
wrote:

> Hi Mark,
>
> We tried to put the changes as suggested by you. Below are the changes that
> we have made in context.xml file.
>
> 


Why this asterisk? *

>
>
> 
> 
> WEB-INF/web.xml
> WEB-INF/tomcat-web.xml
> ${catalina.base}/conf/web.xml
>
>  type="javax.sql.DataSource"/>
>
>  className="org.apache.tomcat.util.http.LegacyCookieProcessor" />
>
> 
> 
>
> 
> 
> 
>
> But after restart still I am getting below errors in tomcat's
> *localhost_access_log.2019-11-29.txt* file.
>
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:45 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
> 172.18.0.3 - - [29/Nov/2019:11:27:46 +] "GET
> /sdm/restcall/v1/platform//healthCheck HTTP/1.0" 404 -
>
> Please help me in correcting the syntax.
>
> Regards
> Kushagra
>
> On Fri, Nov 29, 2019 at 4:02 PM Kushagra Bindal  >
> wrote:
>
> > Hi Mark,
> >
> > Thanks for providing the response.
> >
> > Yes, you are right that we should design our application to remove //
> from
> > being used.
> >
> > I will plan it accordingly, for the provided solution in below. Let me
> try
> > the same and I will revert back to you in case of any further queries and
> > concerns.
> >
> > On Fri, Nov 29, 2019 at 2:56 PM M. Manna  wrote:
> >
> >> HI,
> >>
> >>
> >> On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal <
> bindal.kusha...@gmail.com>
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > We are working on upgrading our enterprise application from 8.5.24 to
> >> > 9.0.27 version.
> >> >
> >> > What we have observed that in earlier version i.e. 8.5.24 we were able
> >> to
> >> > process process a REST URI have  double slash ("//") in it.
> >> >
> >> > But when we are upgrading it to 9.0.27 we found that now the same url
> >> which
> >> > was working earlier it is now throwing 404 status code.
> >> >
> >> > Now, the problem is that we can not remove these double slash (//)
> >> manually
> >> > as it is used widely.
> >> >
> >> > So, can someone please provide a possible solution of this issue?
> >> >
> >>
> >>  Tomcat processes HTTP query and URL using RFC 7230 standards. But
> >> multiple
> >> leading forward slash support was disabled by default for good reasons.
> >> This was done in 8.5.31 due to issues with Http Redirects involving
> >> Servlets.
> >>
> >> If you must use this, you have to modify your application context to add
> >> the override as true - the attribute is called
> >> "allowMultipleLeadingForwardSlashInPath".
> >>
> >> https://tomcat.apache.org/tomcat-8.5-doc/config/context.html
> >>
> >> But I would sincerely recommend that you work on such designs and
> correct
> >> them in your application. There is always a "way". This is one of the
> >> reasons web applications become obsolete requires huge maintenance.
> >>
> >> Thanks,
> >>
> >> >
> >> > --
> >> > Regards,
> >> > Kushagra Bindal
> >> > +91-9013792807
> >> >
> >>
> >
> >
> > --
> > Regards,
> > Kushagra Bindal
> > +91-9013792807
> >
>
>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: SEVERE: A child container failed during start

[M. Manna]

Hi,

On Fri, 29 Nov 2019 at 10:45, Karen Goh 
wrote:

> Hi experts,
>
>
> Basically, I have now upgraded my dynamic MVC web app to use openJDK 13
> and running it with Tomcat 9.0.27.  Windows OS. Eclipse 2019-09.
>
> Have been trying to tackling the problem with no avail.
>
> Would appreciate some tips on how to make these error go away.
>
> Here's the error :
>
> Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase
> startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException:
> org.apache.catalina.LifecycleException: Failed to start component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
> at
> java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
> at
> java.base/java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
> at
> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
> at
> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:262)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:421)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:930)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at org.apache.catalina.startup.Catalina.start(Catalina.java:633)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:344)
> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475)
> Caused by: org.apache.catalina.LifecycleException: Failed to start
> component
> [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/webApp-hi5]]
> at
> org.apache.catalina.util.LifecycleBase.handleSubClassException(LifecycleBase.java:440)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:198)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384)
> at
> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
> at
> java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> at
> org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
> at
> java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:140)
> at
> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:909)
> ... 21 more
> Caused by: java.lang.IllegalArgumentException: Filter mapping specifies an
> unknown filter name [httpHeaderSecurity]
> at
> org.apache.catalina.core.StandardContext.validateFilterMap(StandardContext.java:3009)
> at
> org.apache.catalina.core.StandardContext.addFilterMap(StandardContext.java:2971)
> at
> org.apache.catalina.startup.ContextConfig.configureContext(ContextConfig.java:1288)
> at
> org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1168)
> at
> org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:774)
> at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:301)
> at
> org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123)
> at
> org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5051)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> ... 27 more
>
> Nov 29, 2019 6:25:18 PM org.apache.catalina.core.ContainerBase
> startInternal
> SEVERE: A child container failed during start
> java.util.concurrent.ExecutionException:
> 

Re: Double Slash Support in Tomcat 9.0.27

[M. Manna]

HI,


On Fri, 29 Nov 2019 at 09:00, Kushagra Bindal 
wrote:

> Hi,
>
> We are working on upgrading our enterprise application from 8.5.24 to
> 9.0.27 version.
>
> What we have observed that in earlier version i.e. 8.5.24 we were able to
> process process a REST URI have  double slash ("//") in it.
>
> But when we are upgrading it to 9.0.27 we found that now the same url which
> was working earlier it is now throwing 404 status code.
>
> Now, the problem is that we can not remove these double slash (//) manually
> as it is used widely.
>
> So, can someone please provide a possible solution of this issue?
>

 Tomcat processes HTTP query and URL using RFC 7230 standards. But multiple
leading forward slash support was disabled by default for good reasons.
This was done in 8.5.31 due to issues with Http Redirects involving
Servlets.

If you must use this, you have to modify your application context to add
the override as true - the attribute is called
"allowMultipleLeadingForwardSlashInPath".

https://tomcat.apache.org/tomcat-8.5-doc/config/context.html

But I would sincerely recommend that you work on such designs and correct
them in your application. There is always a "way". This is one of the
reasons web applications become obsolete requires huge maintenance.

Thanks,

>
> --
> Regards,
> Kushagra Bindal
> +91-9013792807
>

Re: [E] Re: Official documentation for running an embedded Tomcat server

[Bauer, Margaret M (Peggy)]

Ease of deployment and build in the AWS world.

On Mon, Nov 25, 2019 at 3:56 PM Behrang Saeedzadeh 
wrote:

> For an example use case, see Spring Boot. It can use an embedded Tomcat and
> build an executable Uber Jar. Then you can start your Web app by running
> java -jar app.jar.
>
> On Tue, 26 Nov. 2019, 2:29 am Mladen Adamović, 
> wrote:
>
> > I wonder why somebody would want to run "embedded Tomcat" and what it
> > actually means?
> > I'm working professionally in software engineering since 2003 and I'm
> > puzzled.
> >
> > From looking into that article, it seems that Java app starts Tomcat, why
> > somebody would want that?
> >
> >
> > On Sun, Nov 24, 2019 at 12:27 AM Behrang Saeedzadeh  >
> > wrote:
> >
> > > I will create a PR if I find the time to write one.
> > >
> > > On Sat, Nov 23, 2019 at 9:40 PM Mark Thomas  wrote:
> > >
> > > > On 23/11/2019 08:17, Behrang Saeedzadeh wrote:
> > > > > Hi all,
> > > > >
> > > > > Are there any official docs for how to run Tomcat as an embedded
> > > server?
> > > > > Searching returns some results such as
> > > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__devcenter.heroku.com_articles_create-2Da-2Djava-2Dweb-2Dapplication-2Dusing-2Dembedded-2Dtomcat=DwIFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=JYuCIQ8r7H-c_yYFTZ4gdv4goO0lCCtidMRmNza4zoA=wnrcnb8haPnDfVwSRvz9Cm28Kj7ACYEr8ZF0JTdMDLM=RoC8ts62eTgtf8yZNCja1R0TFRfhZHsoFF5x7IIPqsM=
> > > > > but I haven't seen any official docs.
> > > > >
> > > > > Are there any?
> > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=http-3A__tomcat.apache.org_tomcat-2D9.0-2Ddoc_api_org_apache_catalina_startup_Tomcat.html=DwIFaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=JYuCIQ8r7H-c_yYFTZ4gdv4goO0lCCtidMRmNza4zoA=wnrcnb8haPnDfVwSRvz9Cm28Kj7ACYEr8ZF0JTdMDLM=S1eZ7tY4G6jD32KhDWaVir7gfQaATAOrJ4qlUGGy5iY=
> > > >
> > > > is the closest thing we have but I suspect parts of it are out of
> date.
> > > > The unit tests are a good source of samples of how to use it.
> > > >
> > > > Care to contribute a how-to page for the docs?
> > > >
> > > > Mark
> > > >
> > > > -
> > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > > > For additional commands, e-mail: users-h...@tomcat.apache.org
> > > >
> > > >
> > >
> >
>


-- 
*Peggy Bauer*
CAO Production Support
214-770-1782

Re: CPU high usage, the reason org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run

[M. Manna]

I’m suspecting it’s the same issue that we found out for 8.5.45 where the
commit didn’t get reverted out in Poll.java

Or maybe not.

Thanks,

On Sun, 24 Nov 2019 at 10:36, Mark Thomas  wrote:

> Tomcat version?
>
> Operating system?
>
> Java version?
>
> Mark
>
>
> On 24/11/2019 09:57, Mladen Adamović wrote:
> > I couldn't find the explanation of this in other threads, I've tried to
> > search the archive.
> >
> > I have a high load average on a server and the reason for that is kernel
> > function futex_wait invoked by java thread.
> >
> > By doing jstack, I see a lot of BLOCKED threads like these:
> > Thread 1725: (state = BLOCKED)
> >  - sun.misc.Unsafe.park(boolean, long) @bci=0 (Compiled frame;
> information
> > may be imprecise)
> >  - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object,
> long)
> > @bci=20, line=215 (Compiled frame)
> >  -
> >
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long)
> > @bci=78, line=2078 (Compiled frame)
> >  - java.util.concurrent.LinkedBlockingQueue.poll(long,
> > java.util.concurrent.TimeUnit) @bci=62, line=467 (Compiled frame)
> >  - org.apache.tomcat.util.threads.TaskQueue.poll(long,
> > java.util.concurrent.TimeUnit) @bci=3, line=85 (Compiled frame)
> >  - org.apache.tomcat.util.threads.TaskQueue.poll(long,
> > java.util.concurrent.TimeUnit) @bci=3, line=31 (Compiled frame)
> >  - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=134, line=1066
> > (Compiled frame)
> >  -
> >
> java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker)
> > @bci=26, line=1127 (Compiled frame)
> >  - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=5, line=617
> > (Compiled frame)
> >  - org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run()
> @bci=4,
> > line=61 (Compiled frame)
> >  - java.lang.Thread.run() @bci=11, line=745 (Compiled frame)
> >
> >
> >
> > What does this
> > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run() actually
> > does when BLOCKED?
> >
> > Should I perhaps lower some tomcat config values or just forget about
> > measuring system resources if the server works? My tomcat is configured
> as
> > follows:
> >
> >
> > my Tomcat is configured as follows:
> >> protocol="org.apache.coyote.http11.Http11AprProtocol"
> >   SSLCertificateFile="/etc/letsencrypt/live/
> numbeo.com/cert.pem"
> >   SSLCertificateKeyFile="/etc/letsencrypt/live/
> > numbeo.com/privkey.pem"
> >   SSLCertificateChainFile="/etc/letsencrypt/live/
> > numbeo.com/chain.pem"
> >   SSLVerifyClient="optional"
> SSLProtocol="TLSv1+TLSv1.1+TLSv1.2"
> >   connectionTimeout="2" acceptCount="3"
> >   acceptorThreadCount="2"
> >   compression="on" maxConnections="5" maxThreads="500"
> >
> >
> compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript,image/svg+xml,image/svg,image/png,image/jpeg"
> >
> >   useSendfile="false"
> >   maxHttpHeaderSize="16392" SSLEnabled="true"
> >   enableLookups="false"
> >   scheme="https" secure="true"   clientAuth="false"
> >  useBodyEncodingForURI="true"
> >   URIEncoding="UTF-8"
> >   />
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Sorry Dumb question earlier - It is in Coyote jar.

We are currently in a rollback state in our prod, but what you reported
above sounds promising. If revert the Coyote jar resolves issues, which is
the earliest/latest version we can revert to?

Thanks,
MAnna

On Tue, 19 Nov 2019 at 10:32, M. Manna  wrote:

> Mark,
>
> On Mon, 18 Nov 2019 at 19:28, Mark Thomas  wrote:
>
>> On 18/11/2019 14:14, Mark Thomas wrote:
>> > On 18/11/2019 12:06, M. Manna wrote:
>> >> Mark and others,
>> >>
>> >> On Mon, 18 Nov 2019 at 12:01, Mark Thomas  wrote:
>> >>
>> >>> OK, it looks like I can reproduce this.
>> >>>
>> >>> Steps to reproduce:
>> >>>
>> >>> - Windows 2016 Server fully patched
>> >>> - Java 1.8.0u144
>> >>> - Install Tomcat 8.5.45 from windows installer
>> >>> - Add tcnative-1.dll (64-bit) from Tomcat Native 1.2.23
>> >>> - Modify server.xml to use Http11AprProtocol on port 8080
>> >>> - Make a single request
>> >>>
>> >>> I then see 1 core running at 100% until the connection times out after
>> >>> 20s. Make another request and a core goes back up to 100% for 20s (the
>> >>> default keep-alive time out).
>> >>>
>> >>
>> >>  I have also successfully reproduced this with making a single request
>> >> (sorry for not replying in the weekend). Not sure how your graph looked
>> >> like, but the Jvisualvm showed me a Sinusoidal modulation curve as
>> soon as
>> >> the request hit the server. and it didn't go down at all.
>> >
>> > I see similar behaviour on Windows 7 but the the CPU usage drops after
>> ~5s.
>> >
>> > A binary search indicates that the issue was introduced with this
>> commit:
>> >
>> >
>> https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
>> >
>> > (this is for 9.0.x - 8.5.x and 7.0.x had similar commits)
>> >
>> > However, that code was removed when APR was switched to a single poll
>> > set.
>>
>> Ah ha. It was removed in 9.0.x but not in 8.5.x (only 9.0.x switched to
>> a single Poller) so it does look like this change is responsible.
>>
>>  Thanks for Debugging this. Are you saying that we will have a patch for
> this? If so, which jar could we replace in 8.5.45 until
> we move to new tomcat?
>
> Thanks,
>
>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: tomcat thread incurring CPU load

[M. Manna]

Mark,

On Mon, 18 Nov 2019 at 19:28, Mark Thomas  wrote:

> On 18/11/2019 14:14, Mark Thomas wrote:
> > On 18/11/2019 12:06, M. Manna wrote:
> >> Mark and others,
> >>
> >> On Mon, 18 Nov 2019 at 12:01, Mark Thomas  wrote:
> >>
> >>> OK, it looks like I can reproduce this.
> >>>
> >>> Steps to reproduce:
> >>>
> >>> - Windows 2016 Server fully patched
> >>> - Java 1.8.0u144
> >>> - Install Tomcat 8.5.45 from windows installer
> >>> - Add tcnative-1.dll (64-bit) from Tomcat Native 1.2.23
> >>> - Modify server.xml to use Http11AprProtocol on port 8080
> >>> - Make a single request
> >>>
> >>> I then see 1 core running at 100% until the connection times out after
> >>> 20s. Make another request and a core goes back up to 100% for 20s (the
> >>> default keep-alive time out).
> >>>
> >>
> >>  I have also successfully reproduced this with making a single request
> >> (sorry for not replying in the weekend). Not sure how your graph looked
> >> like, but the Jvisualvm showed me a Sinusoidal modulation curve as soon
> as
> >> the request hit the server. and it didn't go down at all.
> >
> > I see similar behaviour on Windows 7 but the the CPU usage drops after
> ~5s.
> >
> > A binary search indicates that the issue was introduced with this commit:
> >
> >
> https://github.com/apache/tomcat/commit/fffb08790e642e03f00c5f96a3a61ee09a2c8342
> >
> > (this is for 9.0.x - 8.5.x and 7.0.x had similar commits)
> >
> > However, that code was removed when APR was switched to a single poll
> > set.
>
> Ah ha. It was removed in 9.0.x but not in 8.5.x (only 9.0.x switched to
> a single Poller) so it does look like this change is responsible.
>
>  Thanks for Debugging this. Are you saying that we will have a patch for
this? If so, which jar could we replace in 8.5.45 until
we move to new tomcat?

Thanks,


> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Mark and others,

On Mon, 18 Nov 2019 at 12:01, Mark Thomas  wrote:

> OK, it looks like I can reproduce this.
>
> Steps to reproduce:
>
> - Windows 2016 Server fully patched
> - Java 1.8.0u144
> - Install Tomcat 8.5.45 from windows installer
> - Add tcnative-1.dll (64-bit) from Tomcat Native 1.2.23
> - Modify server.xml to use Http11AprProtocol on port 8080
> - Make a single request
>
> I then see 1 core running at 100% until the connection times out after
> 20s. Make another request and a core goes back up to 100% for 20s (the
> default keep-alive time out).
>

 I have also successfully reproduced this with making a single request
(sorry for not replying in the weekend). Not sure how your graph looked
like, but the Jvisualvm showed me a Sinusoidal modulation curve as soon as
the request hit the server. and it didn't go down at all.

Thanks,

>
> Next steps are to try and track down the root cause.
>
> Mark
>
>
>
> > Mark and M,
> >
> > On 11/13/19 19:31, Mark Thomas wrote:
> >> On November 13, 2019 11:42:34 PM UTC, "M. Manna"
> >>  wrote:
> >>> I see this update on Windows which may have been responsible
> >>> (suspicion only, haven’t rolled it back yet)
> >>>
> >>>
> >>> https://support.microsoft.com/en-gb/help/4494175/kb4494175-intel-micr
> > ocode-updates
> >>>
> >>>
> >>>
> > Was 8.5.45 built on Windows 10 in presence of this update ?
> >
> >> No. Tomcat 8.5.45 and Tomcat Native 1.2.23 were built on a fully
> >> patched at the time of the build Windows 7 64-bit VM.
> > Also it doesn't matter because binaries don't include CPU microcode.
> >
> > It's more likely that the target system has microcode updates such as
> > these that may negatively impact performance.
> >
> > -chris
> >
> >>>
> >>> Thanks,
> >>>
> >>> On Wed, 13 Nov 2019 at 17:55, M. Manna 
> >>> wrote:
> >>>
> >>>> Hi Chris,
> >>>>
> >>>> On Wed, 13 Nov 2019 at 16:27, Christopher Schultz <
> >>>> ch...@christopherschultz.net> wrote:
> >>>>
> >> On 11/13/19 11:20, M. Manna wrote:
> >>>>>>> HI Mark,
> >>>>>>>
> >>>>>>> On Wed, 13 Nov 2019 at 15:38, Mark Thomas
> >>>>>>>  wrote:
> >>>>>>>
> >>>>>>>> On 12/11/2019 19:11, M. Manna wrote:
> >>>>>>>>> HI Mark,
> >>>>>>>>>
> >>>>>>>>> following my previous reply, we have now confirmed
> >>>>>>>>> that it's indeed
> >>>>>>>> 8.5.45
> >>>>>>>>> with APR 1.2.23 that's causing such high JVM CPU
> >>>>>>>>> usage. We used took out 2 out of 50 servers from the
> >>>>>>>>> load balancer config, reverted tomcat, and
> >>>>>>>>> redeployed. With near to identical user traffic, the
> >>>>>>>>> two servers are responding normally without/without
> >>>>>>>>> traffic with 8.5.41. The JVM dump looks a lot better
> >>>>>>>>> with 8.5.41.
> >>>>>>>>>
> >>>>>>>>> We do think that the recent changes in APR and some
> >>>>>>>>> other tomcat jar may have caused compatibility issue
> >>>>>>>>> on Windows server 2016 (64-bit) platform. But
> >>>>>>>>> unfortunately, we cannot pinpoint exactly what change
> >>>>>>>>> may have caused this (i.e. actual OS vs Security
> >>>>>>>>> Updates). With this in mind, we are also being wary
> >>>>>>>>> to move to 8.5.47 as we don't know if the same issue
> >>>>>>>>> will
> >>>>>>>> occur
> >>>>>>>>> again. Since 8.5.41 has been packaged with previously
> >>>>>>>>> accepted
> >>>>>>>> application
> >>>>>>>>> installer, we are more comfortable rolling back.
> >>>>>>>>
> >>>>>>>> Just to confirm, you see this high CPU usage with a
> >>>>>>>> clean install (no additional web applications deployed,
> >>>>>>>> no configuration changes) on

Re: tomcat thread incurring CPU load

[M. Manna]

I see this update on Windows which may have been responsible (suspicion
only, haven’t rolled it back yet)


https://support.microsoft.com/en-gb/help/4494175/kb4494175-intel-microcode-updates

Was 8.5.45 built on Windows 10 in presence of this update ?

Thanks,

On Wed, 13 Nov 2019 at 17:55, M. Manna  wrote:

> Hi Chris,
>
> On Wed, 13 Nov 2019 at 16:27, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> On 11/13/19 11:20, M. Manna wrote:
>> > HI Mark,
>> >
>> > On Wed, 13 Nov 2019 at 15:38, Mark Thomas 
>> > wrote:
>> >
>> >> On 12/11/2019 19:11, M. Manna wrote:
>> >>> HI Mark,
>> >>>
>> >>> following my previous reply, we have now confirmed that it's
>> >>> indeed
>> >> 8.5.45
>> >>> with APR 1.2.23 that's causing such high JVM CPU usage. We used
>> >>> took out 2 out of 50 servers from the load balancer config,
>> >>> reverted tomcat, and redeployed. With near to identical user
>> >>> traffic, the two servers are responding normally
>> >>> without/without traffic with 8.5.41. The JVM dump looks a lot
>> >>> better with 8.5.41.
>> >>>
>> >>> We do think that the recent changes in APR and some other
>> >>> tomcat jar may have caused compatibility issue on Windows
>> >>> server 2016 (64-bit) platform. But unfortunately, we cannot
>> >>> pinpoint exactly what change may have caused this (i.e. actual
>> >>> OS vs Security Updates). With this in mind, we are also being
>> >>> wary to move to 8.5.47 as we don't know if the same issue will
>> >> occur
>> >>> again. Since 8.5.41 has been packaged with previously accepted
>> >> application
>> >>> installer, we are more comfortable rolling back.
>> >>
>> >> Just to confirm, you see this high CPU usage with a clean install
>> >> (no additional web applications deployed, no configuration
>> >> changes) on Windows 2016 DataCenter (64-bit)?
>> >>
>> >> If this is the case, it should be fairly easy to reproduce.
>> >>
>> >> Mark
>> >>
>> >> We do not deploy multiple applications. In fact, Under tomcat
>> > webapps/ROOT we only have one application (ours). Each tomcat
>> > instance is hosted on a VM (total 50) and all of them are
>> > identically configured (server.xml, web.xml, logging, CPU/RAM). We
>> > have not made any other configuration change between 8.5.41 and
>> > 8.5.45. And yes, I agree with you that it's fairly easy to
>> > reproduce.
>>
>> I think the question is whether or not your application is required to
>> be deployed. Can you reproduce this issue with just the stock
>> applications bundled with Tomcat?
>>
>
> My apologies, but our application needs to be deployed. We have not (or
> didn't try in the past) to simply deploy tomcat with stock application (in
> other words, simply starting the tomcat OOB) on our prod servers.
> This is the first time it has hit us with such disparity. I’ll try to
> investigate and get a stock application data. But we may not be able to do
> that quite easily as it’s in our production.
>
> What I can see is that 3 Windows updates may have been responsible for
> this, but we aren’t sure about that. I’ll let you know if we can get
> anything with the stock application instance.
>
> Thanks,
>
> - -chris
>
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3MLscACgkQHPApP6U8
>> pFip5A/+KOg4ZvATDli8zG9ZxniMoPdkOC9LQgVKscjeLZHL/A1gzVLP8UPZSiU7
>> 1+p44WwJ5WGgwe8Ne0NZTFlh7/DZQAGIQZv++Ii9+NRkY5KVP3dYykdoyg1UdUMB
>> Fdu2KNDcsCERYpPqrE/kVk+TQZNI60vY8iTBntc+Og5LsukULZTbX3UO9BzDaqeO
>> WsjVuP6q7hUDBntd+5YqeFKDJ07zEIm5V6vmHAbCOWm3g2B8IXiYkMTXM+ZLld9h
>> 6Th8f+na79taUrxT9TwI1WoR/ZJguJW1c8eRPbykv9/riDrtTQsv0BZy0ZeMhnjv
>> kEwurNMaYjtSSCGOD0e8/chy1rU0/gng99pkmGe0Wiwoob6/6AU0HhE/2RvLKzDY
>> mR4hu+aDaxtog4CD9DQrGenId+pwbJteqhXVCye6V0A3JtobbR+D56cxcUbth1pP
>> skMdXrTWTvVlmsyLfKjPmMiALzOqg0bqvfYH5bEitW1Y8HvCQN5vcht2+EOpchmp
>> zZ0f0LQpXEyr3DJ/GSbPTRKHghMAnrB4yz9jlMvzdWoPX2/JyT3+IQOoe8eRtlD8
>> e6uoQzXoguXFr9J5OLGR5TXdBLx5/obCUWUM2wS/w5TQ3MvV3C5haSKYWTVIcetp
>> XuAzKmK6fKFBHn37pMLd4VELy9Ay+zQmtTrpDJzB9pPwX/gr6JQ=
>> =VqkL
>> -END PGP SIGNATURE-
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: tomcat thread incurring CPU load

[M. Manna]

Hi Chris,

On Wed, 13 Nov 2019 at 16:27, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 11/13/19 11:20, M. Manna wrote:
> > HI Mark,
> >
> > On Wed, 13 Nov 2019 at 15:38, Mark Thomas 
> > wrote:
> >
> >> On 12/11/2019 19:11, M. Manna wrote:
> >>> HI Mark,
> >>>
> >>> following my previous reply, we have now confirmed that it's
> >>> indeed
> >> 8.5.45
> >>> with APR 1.2.23 that's causing such high JVM CPU usage. We used
> >>> took out 2 out of 50 servers from the load balancer config,
> >>> reverted tomcat, and redeployed. With near to identical user
> >>> traffic, the two servers are responding normally
> >>> without/without traffic with 8.5.41. The JVM dump looks a lot
> >>> better with 8.5.41.
> >>>
> >>> We do think that the recent changes in APR and some other
> >>> tomcat jar may have caused compatibility issue on Windows
> >>> server 2016 (64-bit) platform. But unfortunately, we cannot
> >>> pinpoint exactly what change may have caused this (i.e. actual
> >>> OS vs Security Updates). With this in mind, we are also being
> >>> wary to move to 8.5.47 as we don't know if the same issue will
> >> occur
> >>> again. Since 8.5.41 has been packaged with previously accepted
> >> application
> >>> installer, we are more comfortable rolling back.
> >>
> >> Just to confirm, you see this high CPU usage with a clean install
> >> (no additional web applications deployed, no configuration
> >> changes) on Windows 2016 DataCenter (64-bit)?
> >>
> >> If this is the case, it should be fairly easy to reproduce.
> >>
> >> Mark
> >>
> >> We do not deploy multiple applications. In fact, Under tomcat
> > webapps/ROOT we only have one application (ours). Each tomcat
> > instance is hosted on a VM (total 50) and all of them are
> > identically configured (server.xml, web.xml, logging, CPU/RAM). We
> > have not made any other configuration change between 8.5.41 and
> > 8.5.45. And yes, I agree with you that it's fairly easy to
> > reproduce.
>
> I think the question is whether or not your application is required to
> be deployed. Can you reproduce this issue with just the stock
> applications bundled with Tomcat?
>

My apologies, but our application needs to be deployed. We have not (or
didn't try in the past) to simply deploy tomcat with stock application (in
other words, simply starting the tomcat OOB) on our prod servers.
This is the first time it has hit us with such disparity. I’ll try to
investigate and get a stock application data. But we may not be able to do
that quite easily as it’s in our production.

What I can see is that 3 Windows updates may have been responsible for
this, but we aren’t sure about that. I’ll let you know if we can get
anything with the stock application instance.

Thanks,

- -chris

> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3MLscACgkQHPApP6U8
> pFip5A/+KOg4ZvATDli8zG9ZxniMoPdkOC9LQgVKscjeLZHL/A1gzVLP8UPZSiU7
> 1+p44WwJ5WGgwe8Ne0NZTFlh7/DZQAGIQZv++Ii9+NRkY5KVP3dYykdoyg1UdUMB
> Fdu2KNDcsCERYpPqrE/kVk+TQZNI60vY8iTBntc+Og5LsukULZTbX3UO9BzDaqeO
> WsjVuP6q7hUDBntd+5YqeFKDJ07zEIm5V6vmHAbCOWm3g2B8IXiYkMTXM+ZLld9h
> 6Th8f+na79taUrxT9TwI1WoR/ZJguJW1c8eRPbykv9/riDrtTQsv0BZy0ZeMhnjv
> kEwurNMaYjtSSCGOD0e8/chy1rU0/gng99pkmGe0Wiwoob6/6AU0HhE/2RvLKzDY
> mR4hu+aDaxtog4CD9DQrGenId+pwbJteqhXVCye6V0A3JtobbR+D56cxcUbth1pP
> skMdXrTWTvVlmsyLfKjPmMiALzOqg0bqvfYH5bEitW1Y8HvCQN5vcht2+EOpchmp
> zZ0f0LQpXEyr3DJ/GSbPTRKHghMAnrB4yz9jlMvzdWoPX2/JyT3+IQOoe8eRtlD8
> e6uoQzXoguXFr9J5OLGR5TXdBLx5/obCUWUM2wS/w5TQ3MvV3C5haSKYWTVIcetp
> XuAzKmK6fKFBHn37pMLd4VELy9Ay+zQmtTrpDJzB9pPwX/gr6JQ=
> =VqkL
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

HI Mark,

On Wed, 13 Nov 2019 at 15:38, Mark Thomas  wrote:

> On 12/11/2019 19:11, M. Manna wrote:
> > HI Mark,
> >
> > following my previous reply, we have now confirmed that it's indeed
> 8.5.45
> > with APR 1.2.23 that's causing such high JVM CPU usage.
> > We used took out 2 out of 50 servers from the load balancer config,
> > reverted tomcat, and redeployed. With near to identical user traffic, the
> > two servers are responding normally without/without traffic with 8.5.41.
> > The JVM dump looks a lot better with 8.5.41.
> >
> > We do think that the recent changes in APR and some other tomcat jar may
> > have caused compatibility issue on Windows server 2016 (64-bit) platform.
> > But unfortunately, we cannot pinpoint exactly what change may have caused
> > this (i.e. actual OS vs Security Updates). With this in mind, we are also
> > being wary to move to 8.5.47 as we don't know if the same issue will
> occur
> > again. Since 8.5.41 has been packaged with previously accepted
> application
> > installer, we are more comfortable rolling back.
>
> Just to confirm, you see this high CPU usage with a clean install (no
> additional web applications deployed, no configuration changes) on
> Windows 2016 DataCenter (64-bit)?
>
> If this is the case, it should be fairly easy to reproduce.
>
> Mark
>
>  We do not deploy multiple applications. In fact, Under tomcat
webapps/ROOT we only have one application (ours). Each tomcat instance is
hosted on a VM (total 50) and all of them are identically configured
(server.xml, web.xml, logging, CPU/RAM).
 We have not made any other configuration change between 8.5.41 and 8.5.45.
And yes, I agree with you that it's fairly easy to reproduce.


Thanks,


>
> >
> > I would appreciate if this can be looked into.
> >
> > On Tue, 12 Nov 2019 at 11:27, M. Manna  wrote:
> >
> >> Hey Mark (appreciate your response in US holiday time)
> >>
> >> On Tue, 12 Nov 2019 at 07:51, Mark Thomas  wrote:
> >>
> >>> On November 12, 2019 12:54:53 AM UTC, "M. Manna" 
> >>> wrote:
> >>>> Just to give an update again:
> >>>>
> >>>> 1) We reverted the APR to 1.2.21 - but observed no difference.
> >>>> 2) We took 3 thread dumps over 1 min interval (without any user
> >>>> sessions) -
> >>>> All threads are tomcat's internal pool threads.
> >>>>
> >>>> When we checked the thread details (using fasthread.io) - we didn't
> see
> >>>> any
> >>>> of our application stack. Since there is no user traffic, this is
> >>>> coming
> >>> >from tomcat internally. At this stage, we cannot really figure out
> >>>> what's
> >>>> the root cause.
> >>>>
> >>>> Any help is appreciated.
> >>>
> >>> Migrated from what (full version info please)?
> >>>
> >>  from 8.5.41 to 8.5.45 (we migrate 3 times a year, last was in June)
> >>
> >>>
> >>> Operating system exact version?
> >>>
> >>  Microsoft Windows Server 2016 DataCentre (64-bit)
> >>
> >>>
> >>> JRE vendor and exact version?
> >>>
> >>  C:\jdk1.8.0\bin>java.exe -version
> >> java version "1.8.0_162"
> >> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
> >> Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
> >>
> >>
> >>> Do you see the same behavior with the latest 8.5.x and latest Tomcat
> >>> Native?
> >>>
> >>   We are using APR 1.2.23 which I can also see in latest tomcat. Due to
> >> production due diligence we cannot roll to a different version that
> easily.
> >> Normally, we lag behind by 2 monthly releases of tomcat. We also
> reverted
> >> the APR to 1.2.21 (but no difference).
> >>
> >>>
> >>> What triggers this behaviour?
> >>>
> >>  That is quite strange. Due to US holidays, we had a low traffic on our
> >> servers, and nothing has crept in to suggest that it's
> application-driven.
> >> We took one tomcat instance out of 50 instances and removed all user
> >> sessions (i.e. no application activities or threads). Upon restart of
> >> tomcat, the CPU spike lingered past the initial servlet startup period.
> We
> >> monitored that over 1-2 hours but there was no difference.
> >>
> >>>
> >>> How often do you see this behaviour?
> >&g

Re: tomcat thread incurring CPU load

[M. Manna]

HI Mark,

following my previous reply, we have now confirmed that it's indeed 8.5.45
with APR 1.2.23 that's causing such high JVM CPU usage.
We used took out 2 out of 50 servers from the load balancer config,
reverted tomcat, and redeployed. With near to identical user traffic, the
two servers are responding normally without/without traffic with 8.5.41.
The JVM dump looks a lot better with 8.5.41.

We do think that the recent changes in APR and some other tomcat jar may
have caused compatibility issue on Windows server 2016 (64-bit) platform.
But unfortunately, we cannot pinpoint exactly what change may have caused
this (i.e. actual OS vs Security Updates). With this in mind, we are also
being wary to move to 8.5.47 as we don't know if the same issue will occur
again. Since 8.5.41 has been packaged with previously accepted application
installer, we are more comfortable rolling back.

I would appreciate if this can be looked into.

On Tue, 12 Nov 2019 at 11:27, M. Manna  wrote:

> Hey Mark (appreciate your response in US holiday time)
>
> On Tue, 12 Nov 2019 at 07:51, Mark Thomas  wrote:
>
>> On November 12, 2019 12:54:53 AM UTC, "M. Manna" 
>> wrote:
>> >Just to give an update again:
>> >
>> >1) We reverted the APR to 1.2.21 - but observed no difference.
>> >2) We took 3 thread dumps over 1 min interval (without any user
>> >sessions) -
>> >All threads are tomcat's internal pool threads.
>> >
>> >When we checked the thread details (using fasthread.io) - we didn't see
>> >any
>> >of our application stack. Since there is no user traffic, this is
>> >coming
>> >from tomcat internally. At this stage, we cannot really figure out
>> >what's
>> >the root cause.
>> >
>> >Any help is appreciated.
>>
>> Migrated from what (full version info please)?
>>
>  from 8.5.41 to 8.5.45 (we migrate 3 times a year, last was in June)
>
>>
>> Operating system exact version?
>>
>  Microsoft Windows Server 2016 DataCentre (64-bit)
>
>>
>> JRE vendor and exact version?
>>
>  C:\jdk1.8.0\bin>java.exe -version
> java version "1.8.0_162"
> Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)
>
>
>> Do you see the same behavior with the latest 8.5.x and latest Tomcat
>> Native?
>>
>   We are using APR 1.2.23 which I can also see in latest tomcat. Due to
> production due diligence we cannot roll to a different version that easily.
> Normally, we lag behind by 2 monthly releases of tomcat. We also reverted
> the APR to 1.2.21 (but no difference).
>
>>
>> What triggers this behaviour?
>>
>  That is quite strange. Due to US holidays, we had a low traffic on our
> servers, and nothing has crept in to suggest that it's application-driven.
> We took one tomcat instance out of 50 instances and removed all user
> sessions (i.e. no application activities or threads). Upon restart of
> tomcat, the CPU spike lingered past the initial servlet startup period. We
> monitored that over 1-2 hours but there was no difference.
>
>>
>> How often do you see this behaviour?
>>
> We took 2 sets of data
> 1) 3 Jstack dump based on 10 seconds interval.
> 2) 3 jstack dump based on 1 min interval.
>
> Both the above reveals that all background threads (http, pool etc.) were
> from tomcat. We didn't have any application threads lingered in those 3
> samples. So yes we see this almost all the time if we take samples.
> However, when we compared with pre-production instances (with Windows
> server R2 x64 bit), we don't see such abnormal spike. In fact, the
> application instance doesn't incur such a big CPU spike. Whilst composing
> this email, I am now thinking if the APR is indeed incompatible with
> WIndows Server R2 (or the presence of any Windows Updates) which blocks the
> native poll() call longer than usual.
>
> An example is that on Windows Server 2012 - APR poll() call takes about
> 30% CPU time - but with Windows Server 2016 it's almost always 95%.
>
>
>>
>> And anything else you think might be relevant.
>>
>
> We are using end-2-end encryption using APR (with Certificate and
> SSLConfig resource setup in server.xml). But it's survived past 3 tomcat
> upgrades without any issue.
> Except OS we don't have any obvious culprit identified at the moment.
>
> Thanks,
>
>>
>> Mark
>>
>> >
>> >Thanks,
>> >
>> >On Mon, 11 Nov 2019 at 20:57, M. Manna  wrote:
>> >
>> >> Hello All,
>> >>
>> >> Any thoughts regarding this? Slightly clueless at thi

Re: tomcat thread incurring CPU load

[M. Manna]

Hey Mark (appreciate your response in US holiday time)

On Tue, 12 Nov 2019 at 07:51, Mark Thomas  wrote:

> On November 12, 2019 12:54:53 AM UTC, "M. Manna" 
> wrote:
> >Just to give an update again:
> >
> >1) We reverted the APR to 1.2.21 - but observed no difference.
> >2) We took 3 thread dumps over 1 min interval (without any user
> >sessions) -
> >All threads are tomcat's internal pool threads.
> >
> >When we checked the thread details (using fasthread.io) - we didn't see
> >any
> >of our application stack. Since there is no user traffic, this is
> >coming
> >from tomcat internally. At this stage, we cannot really figure out
> >what's
> >the root cause.
> >
> >Any help is appreciated.
>
> Migrated from what (full version info please)?
>
 from 8.5.41 to 8.5.45 (we migrate 3 times a year, last was in June)

>
> Operating system exact version?
>
 Microsoft Windows Server 2016 DataCentre (64-bit)

>
> JRE vendor and exact version?
>
 C:\jdk1.8.0\bin>java.exe -version
java version "1.8.0_162"
Java(TM) SE Runtime Environment (build 1.8.0_162-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.162-b12, mixed mode)


> Do you see the same behavior with the latest 8.5.x and latest Tomcat
> Native?
>
  We are using APR 1.2.23 which I can also see in latest tomcat. Due to
production due diligence we cannot roll to a different version that easily.
Normally, we lag behind by 2 monthly releases of tomcat. We also reverted
the APR to 1.2.21 (but no difference).

>
> What triggers this behaviour?
>
 That is quite strange. Due to US holidays, we had a low traffic on our
servers, and nothing has crept in to suggest that it's application-driven.
We took one tomcat instance out of 50 instances and removed all user
sessions (i.e. no application activities or threads). Upon restart of
tomcat, the CPU spike lingered past the initial servlet startup period. We
monitored that over 1-2 hours but there was no difference.

>
> How often do you see this behaviour?
>
We took 2 sets of data
1) 3 Jstack dump based on 10 seconds interval.
2) 3 jstack dump based on 1 min interval.

Both the above reveals that all background threads (http, pool etc.) were
from tomcat. We didn't have any application threads lingered in those 3
samples. So yes we see this almost all the time if we take samples.
However, when we compared with pre-production instances (with Windows
server R2 x64 bit), we don't see such abnormal spike. In fact, the
application instance doesn't incur such a big CPU spike. Whilst composing
this email, I am now thinking if the APR is indeed incompatible with
WIndows Server R2 (or the presence of any Windows Updates) which blocks the
native poll() call longer than usual.

An example is that on Windows Server 2012 - APR poll() call takes about 30%
CPU time - but with Windows Server 2016 it's almost always 95%.


>
> And anything else you think might be relevant.
>

We are using end-2-end encryption using APR (with Certificate and SSLConfig
resource setup in server.xml). But it's survived past 3 tomcat upgrades
without any issue.
Except OS we don't have any obvious culprit identified at the moment.

Thanks,

>
> Mark
>
> >
> >Thanks,
> >
> >On Mon, 11 Nov 2019 at 20:57, M. Manna  wrote:
> >
> >> Hello All,
> >>
> >> Any thoughts regarding this? Slightly clueless at this point, so any
> >> direction will be appreciated.
> >>
> >> We are seeing the poll taking all the CPU time. We are using
> >> OperatingSystemMXBean.getProcessCpuLoad() and
> >> OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then
> >x100 to
> >> get the pct).
> >>
> >> Thanks,
> >>
> >>
> >> On Mon, 11 Nov 2019 at 17:46, M. Manna  wrote:
> >>
> >>> Hello,
> >>>
> >>> after migrating to 8.5.45, we are seeing a lot of cpu load by
> >following
> >>> JVM thread dump:
> >>>
> >>> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
> >>> cpu=172902703125000 : cpuLoad= 74.181015
> >>>
> >>> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
> >>> LockOwnerName:null
> >>>
> >>> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
> >>> org.apache.tomcat.jni.Poll.poll(Poll.java:-2)
> >>>
> >>> at
> >>>
> >org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)
> >>>
> >>> at java.lang.Thread.run(Thread.java:748)
> >>>
> >>>
> >>> These are coming after 2-3 successful jvm dump. Is this something
> >>> familiar to anybody?
> >>>
> >>> Thanks,
> >>>
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Just to give an update again:

1) We reverted the APR to 1.2.21 - but observed no difference.
2) We took 3 thread dumps over 1 min interval (without any user sessions) -
All threads are tomcat's internal pool threads.

When we checked the thread details (using fasthread.io) - we didn't see any
of our application stack. Since there is no user traffic, this is coming
from tomcat internally. At this stage, we cannot really figure out what's
the root cause.

Any help is appreciated.

Thanks,

On Mon, 11 Nov 2019 at 20:57, M. Manna  wrote:

> Hello All,
>
> Any thoughts regarding this? Slightly clueless at this point, so any
> direction will be appreciated.
>
> We are seeing the poll taking all the CPU time. We are using
> OperatingSystemMXBean.getProcessCpuLoad() and
> OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then x100 to
> get the pct).
>
> Thanks,
>
>
> On Mon, 11 Nov 2019 at 17:46, M. Manna  wrote:
>
>> Hello,
>>
>> after migrating to 8.5.45, we are seeing a lot of cpu load by following
>> JVM thread dump:
>>
>> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
>> cpu=172902703125000 : cpuLoad= 74.181015
>>
>> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
>> LockOwnerName:null
>>
>> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
>> org.apache.tomcat.jni.Poll.poll(Poll.java:-2)
>>
>> at
>> org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)
>>
>> at java.lang.Thread.run(Thread.java:748)
>>
>>
>> These are coming after 2-3 successful jvm dump. Is this something
>> familiar to anybody?
>>
>> Thanks,
>>
>

Re: tomcat thread incurring CPU load

[M. Manna]

Hello All,

Any thoughts regarding this? Slightly clueless at this point, so any
direction will be appreciated.

We are seeing the poll taking all the CPU time. We are using
OperatingSystemMXBean.getProcessCpuLoad() and
OperatingSystemMXBean.getSystemCpuLoad() to get our metrics (then x100 to
get the pct).

Thanks,


On Mon, 11 Nov 2019 at 17:46, M. Manna  wrote:

> Hello,
>
> after migrating to 8.5.45, we are seeing a lot of cpu load by following
> JVM thread dump:
>
> "https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
> cpu=172902703125000 : cpuLoad= 74.181015
>
> BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
> LockOwnerName:null
>
> WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
> org.apache.tomcat.jni.Poll.poll(Poll.java:-2)
>
> at
> org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)
>
> at java.lang.Thread.run(Thread.java:748)
>
>
> These are coming after 2-3 successful jvm dump. Is this something familiar
> to anybody?
>
> Thanks,
>

tomcat thread incurring CPU load

[M. Manna]

Hello,

after migrating to 8.5.45, we are seeing a lot of cpu load by following JVM
thread dump:

"https-openssl-apr-0.0.0.0-8443-Poller" : 102 : RUNNABLE :
cpu=172902703125000 : cpuLoad= 74.181015

BlockedCount:8464 BlockedTime:0 LockName:null LockOwnerID:-1
LockOwnerName:null

WaitedCount:5397 WaitedTime:0 InNative:false IsSuspended:false at
org.apache.tomcat.jni.Poll.poll(Poll.java:-2)

at
org.apache.tomcat.util.net.AprEndpoint$Poller.run(AprEndpoint.java:1547)

at java.lang.Thread.run(Thread.java:748)


These are coming after 2-3 successful jvm dump. Is this something familiar
to anybody?

Thanks,

Re: SameSite cookies

[M. Manna]

Hey Chris,

Interesting question.

samesite attribute is also to protect cookies from possible cross-site
attacks. Even if you have super domain cookies, using strict/lax shouldn't
make any difference for you, or does it?

Thanks,

On Fri, 8 Nov 2019 at 15:04, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> All,
>
> I'm looking at using "samesite" cookies within my application. It
> looks as simple as setting the "sameSite" attribute appropriately on
> the CookieProcessor for the , which isn't there in a default
> configuration. So you just have to add it:
>
> 
>
>
>
> 
>
> Cool, now my JSESSIONID cookies are coming back with the SameSite=Lax
> parameter.
>
> But it also applies to all the other cookies my application creates.
> It looks like there is no way to set/reset this parameter on an
> individual-cookie basis. That would require a change to the Servlet
> API, right?
>
> I'm okay with SameSite being applied to ALL my cookies, but maybe not
> everybody is. Are there any workarounds for this?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3Fg/kACgkQHPApP6U8
> pFjfYg/+LSQ1WHvr/Ds7yskd3C7AFF5jBZaNPO4+I3M+5urpQqvy0Gk2use136rA
> rEoct2iTauj2PY9oIplMUqFuaeiOiO5e0VE5//jp7FhnBe4yRxI0mUGzkvX/d/3j
> e37Hm257iiteJ7q19b0uCTd867ZD2dyxupZYHaNQpeviiV+kyGwsv9KupHeIDpyk
> E2AvZ/lIsRQ6tJ0jkNWiHBlpNgXVhIdabJ9WJHFbaqQ4oHPhcKZaMvthoDFnUKGS
> JpyZjmP9TbNjIWE2I2zhwkKC4lTsiHkpeyccR/UC1V4SQs63rUxpGRCGjQ/Jk4p9
> o6nCfI9zJuH3nsAV/sGasXuoPwzDpszsZT8Q8feun9jmfLz6aHynDR2b65Xq1dwc
> OjPX/5QSk6TrlgXQ0jnqlfIhWp1A9e8OF2HUEKW1XgmNFu5CWlsUSYdHlsMBNEF2
> gaciDa1IvYDnfmawJPgXxSUu6csBboiqRsr4RvCcjCSm4mERkcIm8UsYUHJG+c7Z
> IhWc3pszJ5e/IV/w1iVZK34JL+qZcTImR9gThViNJnECW7Y7E5xbYBTOqxkjUUFR
> 6AUvtaW9vMZe1ArsZKKWdpb1f/DjK70KeQsyVcK8zhYbQb8uSI818vo6LV7andpU
> bfifGiSSWuT1ZHdwMOaCrIf++ew1xc45yPb4qsZqTQ95jkuHhng=
> =QbXx
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Intermittent JSP Caching/Compiling Issue while under load

[M. Manna]

I’m just trying to understand, is there really a plausible solution here ?
Unless we have loadbalanced tomcat instances, can we truly ever stop such
behaviour (or more importantly, does it make sense to do so)?

For my use case, We do it in production almost every other day for
patching, but we do it on our 60 servers over a duration of 15-20 minutes
(and by rolling 1-by-1). That said, this may not be an acceptable
delay/solution for others. Also, if it happens to be a critical piece
(index.jsp or something more client-faces), you may not be able to wait
that long.

It’s be good to know what others think.

Regards,


On Mon, 4 Nov 2019 at 22:55, Alex O'Ree  wrote:

> Sounds a lot like the issue I reported a few months ago
>
> On Mon, Nov 4, 2019, 3:12 PM Tim K  wrote:
>
> > On Mon, Nov 4, 2019, 10:30 AM Mark Thomas  wrote:
> >
> > >
> > > Thanks. That helps as it means the issue should be reproducible on a
> > > single, stand-alone instance.
> > >
> > > Mark
> > >
> >
> > I was able to reproduce this behavior with a single server running a
> > vanilla 9.0.21 using the example hello.jsp file...  I was hitting the url
> > every 0.5 seconds.
> >
> > >
> >
>

Re: SameSite Cookie Setup Not Working

[M. Manna]

Apologies, but got this resolved. the httpOly attribute was missing from
one of the apps. I have now set it globally for all my apps.

Thanks,

On Tue, 22 Oct 2019 at 15:34, M. Manna  wrote:

> Hello,
>
> As per the official documentation, I setup my same site cookie using
> Rfc62665CookieProcessor and set everything in "strict" mode.
>
> However, when I restarted my server, I only see httpOnly, secure - but not
> SameSite checked under browser's developer console.
>
> Could someone please help me understand whether something has been missed
> at my side? And yes, I am using tomcat 8.5.45 (as I read that it's been
> since 8.5.42). Otherwise, cataina bootstrapping would simply say that
> there's no samesitecookies attribute.
>
> Regards,
>

SameSite Cookie Setup Not Working

[M. Manna]

Hello,

As per the official documentation, I setup my same site cookie using
Rfc62665CookieProcessor and set everything in "strict" mode.

However, when I restarted my server, I only see httpOnly, secure - but not
SameSite checked under browser's developer console.

Could someone please help me understand whether something has been missed
at my side? And yes, I am using tomcat 8.5.45 (as I read that it's been
since 8.5.42). Otherwise, cataina bootstrapping would simply say that
there's no samesitecookies attribute.

Regards,

Re: Session Size Calculation Question

[M. Manna]

Amazing! That's what I love about Tomcat :)

Thank you Luis.

On Sun, 20 Oct 2019 at 12:21, Luis Rodríguez Fernández 
wrote:

> Hello M.Manna,
>
> Yes, probably SESSIONS.ser can give you an idea. Maybe if you want to get
> more accurate results perhaps you can
>
> 1. Do it yourself via JMX [1]
> 2. Give a try to psi-probe [2], it seems that it has everything that you
> need
>
> Hope it helps,
>
> Luis
>
> [1]
>
> https://stackoverflow.com/questions/19827650/java-monitor-active-web-sessions
> [2]
>
> https://cwiki.apache.org/confluence/display/tomcat/AddOns#AddOns-WebApplications
>
>
>
>
>
>
> El sáb., 19 oct. 2019 a las 2:51, M. Manna ()
> escribió:
>
> > Hello,
> >
> > We are trying to do some calculation for our user session size (or near
> > estimate of it).
> >
> > What we understand is that upon a "Graceful" shutdown, Catalina Host will
> > write out the serializable values of all session into a SESSIONS.ser file
> > in the main servlet's work directory. If this is correct, then the size
> of
> > the the SESSIONS.ser file (assuming 1 user has logged in) would probably
> > (and approximately) equal to a user's session size?
> >
> > We do understand that not all the info in the serializable session may
> not
> > be required. However, given that StandardManager does the privileged load
> > based on reading the entire SESSIONS.ser file, we thought it would be a
> > more appropriate way of calculating the session size.
> >
> > Any guidance or help is appreciated, and apologies for making any
> incorrect
> > assumption.
> >
> > Thanks,
> >
>
>
> --
>
> "Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."
>
> - Samuel Beckett
>

Session Size Calculation Question

[M. Manna]

Hello,

We are trying to do some calculation for our user session size (or near
estimate of it).

What we understand is that upon a "Graceful" shutdown, Catalina Host will
write out the serializable values of all session into a SESSIONS.ser file
in the main servlet's work directory. If this is correct, then the size of
the the SESSIONS.ser file (assuming 1 user has logged in) would probably
(and approximately) equal to a user's session size?

We do understand that not all the info in the serializable session may not
be required. However, given that StandardManager does the privileged load
based on reading the entire SESSIONS.ser file, we thought it would be a
more appropriate way of calculating the session size.

Any guidance or help is appreciated, and apologies for making any incorrect
assumption.

Thanks,

tomcat with SiteMinder

[Bauer, Margaret M (Peggy)]

Has anyone used tomcat with SiteMinder without having a webserver in front
of it?  If so, where can I find the how to?

thank you,

*Peggy *