Re: Tomcat 9.0.xx JDK Version Support and EOL

[Christopher Schultz]

Chaitanya,

On 6/5/24 09:11, Chaitanya Gopisetti wrote:

Also can you update on the End of life expected date for Tomcat 9.0.x version

-Original Message-
From: Christopher Schultz 
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version Support and EOL

Chaitanya,

On 6/5/24 08:47, Chaitanya Gopisetti wrote:

It was mentioned that Tomcat 9.0.x supports java 8 and later. So
wanted to know whether it supports Jdk 21? Also wanted to know the End
of life expected date for Tomcat 9.0.x version.


Tomcat 9 should run jut fine on any Java version from 8 up through the latest 
release (currently Java 21).


Sorry, that's the latest LTS version. The latest released version is 
Java 22 and Tomcat should continue to work there as well.


The supported Java version is "8 *or later*" (emphasis mine) which 
pretty much means that we should support any version after Java 8 as well.


We have a minimum Java version only because (1) The Servlet Spec 
includes a minimum supported Java version and (2) we use features which 
require that version of Java as well.


Note that Tomcat 9 must be /built/ using Java 17 or later, but targets 
Java 8 for class file format, etc.


-chris

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

Re: Tomcat 9.0.xx JDK Version Support and EOL

[Mark Thomas]

On 05/06/2024 15:11, Chaitanya Gopisetti wrote:

Also can you update on the End of life expected date for Tomcat 9.0.x version


Best guess (based on the next major release being in ~3 years time) 
right now is 31 March 2027 for 9.0.x noting that a 9.10.x will follow to 
retain supoprt for the Java EE APIs.


We will provide at least 12 months notice of any offical EOL date for 9.0.x.

We expect to support 9.x for an extended period of time.

When 10.x reaches EOL so will 9.10.x and then we'll have 9.11.x and so on.

Mark



-Original Message-
From: Christopher Schultz 
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version Support and EOL

Chaitanya,

On 6/5/24 08:47, Chaitanya Gopisetti wrote:

It was mentioned that Tomcat 9.0.x supports java 8 and later. So
wanted to know whether it supports Jdk 21? Also wanted to know the End
of life expected date for Tomcat 9.0.x version.


Tomcat 9 should run jut fine on any Java version from 8 up through the latest 
release (currently Java 21).

-chris

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


To the extent permitted by law, we may monitor electronic communications for 
the purposes of ensuring compliance with our legal and regulatory obligations 
and internal policies. We may also collect email traffic headers for analyzing 
patterns of network traffic and managing client relationships. For additional 
information see https://blueyonder.com/privacy-policy.

-
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: Tomcat 9.0.xx JDK Version Support and EOL

[Chaitanya Gopisetti]

Also can you update on the End of life expected date for Tomcat 9.0.x version

-Original Message-
From: Christopher Schultz  
Sent: Wednesday, June 5, 2024 6:37 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat 9.0.xx JDK Version Support and EOL

Chaitanya,

On 6/5/24 08:47, Chaitanya Gopisetti wrote:
> It was mentioned that Tomcat 9.0.x supports java 8 and later. So 
> wanted to know whether it supports Jdk 21? Also wanted to know the End 
> of life expected date for Tomcat 9.0.x version.

Tomcat 9 should run jut fine on any Java version from 8 up through the latest 
release (currently Java 21).

-chris

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


To the extent permitted by law, we may monitor electronic communications for 
the purposes of ensuring compliance with our legal and regulatory obligations 
and internal policies. We may also collect email traffic headers for analyzing 
patterns of network traffic and managing client relationships. For additional 
information see https://blueyonder.com/privacy-policy.

Re: Tomcat 9.0.xx JDK Version Support and EOL

[Christopher Schultz]

Chaitanya,

On 6/5/24 08:47, Chaitanya Gopisetti wrote:

It was mentioned that Tomcat 9.0.x supports java 8 and later. So
wanted to know whether it supports Jdk 21? Also wanted to know the
End of life expected date for Tomcat 9.0.x version.


Tomcat 9 should run jut fine on any Java version from 8 up through the 
latest release (currently Java 21).


-chris

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

Tomcat 9.0.xx JDK Version Support and EOL

[Chaitanya Gopisetti]

Hi,

It was mentioned that Tomcat 9.0.x supports java 8 and later. So wanted to know 
whether it supports Jdk 21?
Also wanted to know the End of life expected date for Tomcat 9.0.x version.

Regards,
Chaitanya

To the extent permitted by law, we may monitor electronic communications for 
the purposes of ensuring compliance with our legal and regulatory obligations 
and internal policies. We may also collect email traffic headers for analyzing 
patterns of network traffic and managing client relationships. For additional 
information see https://blueyonder.com/privacy-policy.

RE: Migrating from Tomcat 9.0.x to 10.1.x

[Amit Pande]

Thank you, Chris, for the feedback.

The changes are needed in the Spring WebSocket library to ensure Tomcat 10.1 
compatibility.
https://github.com/spring-projects/spring-framework/pull/29434

As I understand, this means I should be updating the Spring libraries used in 
the applications to be deployed with Tomcat 10.1.

I was exploring the possibility of performing Tomcat 10 upgrade independent of 
the upgrades of TPIPs used the application (mainly Spring 5 to 6). And using 
migration tool seemed a very promising approach.
Now looking at issue like this, seems like it's ideal to have both Tomcat 
upgrade and the application TPIPs upgrade go together.

Thanks,
Amit


-Original Message-
From: Christopher Schultz 
Sent: Thursday, April 4, 2024 9:37 PM
To: users@tomcat.apache.org
Subject: Re: Migrating from Tomcat 9.0.x to 10.1.x


CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. If you believe this is a phishing email, use the Report to 
Cybersecurity icon in Outlook.



Amit,

On 4/4/24 22:21, Amit Pande wrote:
> I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1 
> (10.1.20).
>
> https://tomcat.apache.org/migration-10.1.html Using the migration tool, I 
> have migrated the applications (which use Spring libraries 5.x).
>
> While testing the migrated apps( which use web socket), ran into:
>
>
> org.springframework.web.util.NestedServletException: Handler dispatch
> failed; nested exception is java.lang.NoSuchMethodError: 'void
> org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta
> .servlet.http.HttpServletRequest,
> jakarta.servlet.http.HttpServletResponse,
> jakarta.websocket.server.ServerEndpointConfig, java.util.Map)
>
>
> https://gith/
> ub.com%2Fapache%2Ftomcat%2Fblob%2F9.0.x%2Fjava%2Forg%2Fapache%2Ftomcat
> %2Fwebsocket%2Fserver%2FWsServerContainer.java&data=05%7C02%7CAmit.Pan
> de%40veritas.com%7C2650bfb140d94911624408dc55195c23%7Cfc8e13c0422c4c55
> b3eaca318e6cac32%7C0%7C0%7C638478814607427868%7CUnknown%7CTWFpbGZsb3d8
> eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0
> %7C%7C%7C&sdata=w69RggozFPZcifxDJOHnII9jtZJJ29qZQSkDNNFYTzE%3D&reserve
> d=0
>
> * @deprecated This method will be removed in Apache Tomcat 10.1 onwards. 
> It has been replaced by
>   * {@link #upgradeHttpToWebSocket(Object, Object, 
> ServerEndpointConfig, Map)}
>   */
>  @Deprecated
>  public void doUpgrade(HttpServletRequest request, HttpServletResponse 
> response, ServerEndpointConfig sec,
>  Map pathParams) throws ServletException, 
> IOException {
>  UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
>  }
>
> Is this an issue with the migration tool to appropriately replace the removed 
> methods?
>
> Or the applications using web sockets with Tomcat 9.x are required to be 
> updated before moving to Tomcat 10.1, instead of using the migration tool as 
> an intermediate step to upgrade to Tomcat 10.1 without having to update the 
> applications at the same time?
> FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.

The Migration Tool doesn't rewrite your code, it only rewrites the class names 
referenced by your class files. (Okay, it also re-writes strings in your files 
which match those class names as well.) But it will not change method calls. It 
is not a Deprecation Cleanup Tool.

You should change your Java EE-compatible application to use 
upgradeHttpToWebSocket(Object, Object, ServerEndpointConfig, Map) first, then 
run the Migration Tool on your application.

-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: Migrating from Tomcat 9.0.x to 10.1.x

[Christopher Schultz]

Amit,

On 4/4/24 22:21, Amit Pande wrote:

I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1 
(10.1.20).

https://tomcat.apache.org/migration-10.1.html Using the migration tool, I have 
migrated the applications (which use Spring libraries 5.x).

While testing the migrated apps( which use web socket), ran into:


org.springframework.web.util.NestedServletException: Handler dispatch failed; 
nested exception is java.lang.NoSuchMethodError: 'void 
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta.servlet.http.HttpServletRequest,
 jakarta.servlet.http.HttpServletResponse, 
jakarta.websocket.server.ServerEndpointConfig, java.util.Map)


https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/websocket/server/WsServerContainer.java

* @deprecated This method will be removed in Apache Tomcat 10.1 onwards. It 
has been replaced by
  * {@link #upgradeHttpToWebSocket(Object, Object, 
ServerEndpointConfig, Map)}
  */
 @Deprecated
 public void doUpgrade(HttpServletRequest request, HttpServletResponse 
response, ServerEndpointConfig sec,
 Map pathParams) throws ServletException, 
IOException {
 UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
 }

Is this an issue with the migration tool to appropriately replace the removed 
methods?

Or the applications using web sockets with Tomcat 9.x are required to be 
updated before moving to Tomcat 10.1, instead of using the migration tool as an 
intermediate step to upgrade to Tomcat 10.1 without having to update the 
applications at the same time?
FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.


The Migration Tool doesn't rewrite your code, it only rewrites the class 
names referenced by your class files. (Okay, it also re-writes strings 
in your files which match those class names as well.) But it will not 
change method calls. It is not a Deprecation Cleanup Tool.


You should change your Java EE-compatible application to use 
upgradeHttpToWebSocket(Object, Object, ServerEndpointConfig, Map) first, 
then run the Migration Tool on your application.


-chris

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

Migrating from Tomcat 9.0.x to 10.1.x

[Amit Pande]

Hello,

I am in the process of migrating from Tomcat 9 (9.0.87) to Tomcat 10.1 
(10.1.20).

https://tomcat.apache.org/migration-10.1.html Using the migration tool, I have 
migrated the applications (which use Spring libraries 5.x).

While testing the migrated apps( which use web socket), ran into:


org.springframework.web.util.NestedServletException: Handler dispatch failed; 
nested exception is java.lang.NoSuchMethodError: 'void 
org.apache.tomcat.websocket.server.WsServerContainer.doUpgrade(jakarta.servlet.http.HttpServletRequest,
 jakarta.servlet.http.HttpServletResponse, 
jakarta.websocket.server.ServerEndpointConfig, java.util.Map)


https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/tomcat/websocket/server/WsServerContainer.java

   * @deprecated This method will be removed in Apache Tomcat 10.1 onwards. It 
has been replaced by
 * {@link #upgradeHttpToWebSocket(Object, Object, 
ServerEndpointConfig, Map)}
 */
@Deprecated
public void doUpgrade(HttpServletRequest request, HttpServletResponse 
response, ServerEndpointConfig sec,
Map pathParams) throws ServletException, 
IOException {
UpgradeUtil.doUpgrade(this, request, response, sec, pathParams);
}

Is this an issue with the migration tool to appropriately replace the removed 
methods?

Or the applications using web sockets with Tomcat 9.x are required to be 
updated before moving to Tomcat 10.1, instead of using the migration tool as an 
intermediate step to upgrade to Tomcat 10.1 without having to update the 
applications at the same time?
FWIW, Spring 5 to Spring 6 is a major upgrade and Tomcat 10 is a requirement.

Appreciate the guidance.

Thanks,
Amit

Re: EOL for Tomcat 9.0.x and Tomcat 10.1.x

[Mark Thomas]

On 19/12/2023 12:32, Kaluva S wrote:

Hi,
We are planning to migrate from tomcat 9.0.x to Tomcat 10.1.x but want to
know about EOL  for both the releases. On the official tomcat website, we
couldn't find any information about this.
If anyone knows, please share so that we will plan accordingly.


There are currently no firm EOL dates for either 9.0.x or 10.1.x.

Based on past experience, 9.0.x is likely to be EOL some time around 31 
March 2027 and 10.1.x is likely to be EOL some time around 31 March 2030.


However those dates are driven by the expected stability dates of Tomcat 
12 and Tomcat 13 (neither of which have even been started yet) and which 
in turn depend on the release dates for Jakarta EE 12 and Jakarta EE 13 
which also have not been started. So the dates above really are just a 
best guess at this point.


Further, since 9.x is the last branch to support Java EE, it is our 
intention to continue 9.x support beyond the 9.0.x EOL. The current 
expectation is that there would be a 9.10.x release branch that would 
track 10.1.x with the minimal changes required to implemented to Java EE 
API rather than the Jakarta EE API.


When 10.1.x reaches EOL so will 9.10.x which would then be replaced by 
9.11.x which would track 11.0.x. And so on for as long as there was 
(sufficient) demand for Java EE support. Sufficient is deliberately 
subjective. It will depend on the level of demand and the effort 
required. As volunteers, there is only so long we can support things for.


Mark

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

EOL for Tomcat 9.0.x and Tomcat 10.1.x

[Kaluva S]

Hi,
We are planning to migrate from tomcat 9.0.x to Tomcat 10.1.x but want to
know about EOL  for both the releases. On the official tomcat website, we
couldn't find any information about this.
If anyone knows, please share so that we will plan accordingly.

Thanks in advance,
Sreenivas K.

Re: Tomcat 9.0.x on Windows crashing

[Christopher Schultz]

Daniel,

On 8/28/23 14:37, Daniel Savard wrote:

Le jeu. 24 août 2023 à 13:06, Christopher Schultz <
ch...@christopherschultz.net> a écrit :


Daniel,

On 8/23/23 13:03, Daniel Savard wrote:

I didn't specify the actual Tomcat version because the problem occurs

under

all versions. We are running a commercial web application and all of

sudden

after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve

this

problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself,

but

the tuning of the VM.


What kind of environment (e.g. Windows vs UNIX, etc.)? What is running
the service? Are there log files for the service which are different
than usual (e.g. syslog vs catalina.out)?

What are your memory settings, and how much physical RAM do you have?

It's unlikely that the JVM is just disappearing without leaving any
trace. If you are on Linux, maybe you are the victim of oome-killer?
That will show in the syslog with a whole lot of output. Search syslog
for "oom" and you will probably find it right away if that's the cause.

-chris



Hi Chris,

Thanks for the answer.  It is running on Windows and it is running as a
service which is configured to restart if it fails. No different log files
at my knowledge except application logs.

There is 14 GB physical RAM on this server. Initial memory pool is 4 GB and
maximum memory pool is 8 GB.

Well, the only thing I can say is Tomcat is failing at some point and
shutting itself down or being shutdown or killed, I cannot say the JVM
itself gets killed.


Windows... so Linux oome killer isn't a likely cause :)

"Windows Service" could mean a lot of things. Are you using the 
procrun-based service that Tomcat ships with? That should create 
stderr-* and stdout-* files in your logs directory which will be 
completely different than application logs.


Look at catalina.out, stderr/stdout and see if you see anything in there 
around the suspected time of termination.


-chris

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

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le jeu. 24 août 2023 à 13:06, Christopher Schultz <
ch...@christopherschultz.net> a écrit :

> Daniel,
>
> On 8/23/23 13:03, Daniel Savard wrote:
> > I didn't specify the actual Tomcat version because the problem occurs
> under
> > all versions. We are running a commercial web application and all of
> sudden
> > after a while Tomcat is crashing without issuing any message. It is very
> > likely due to the application. But the vendor was of no help to solve
> this
> > problem which has existed for a long time. I suspect something like
> > insufficient memory allocated to the VM or something like that. Is there
> > anything I can do to gather more information on the root cause of this
> > issue?
> >
> > Tomcat is running as a service and is restarted automatically if it
> > crashes. Again, the problem is very unlikely to be with Tomcat itself,
> but
> > the tuning of the VM.
>
> What kind of environment (e.g. Windows vs UNIX, etc.)? What is running
> the service? Are there log files for the service which are different
> than usual (e.g. syslog vs catalina.out)?
>
> What are your memory settings, and how much physical RAM do you have?
>
> It's unlikely that the JVM is just disappearing without leaving any
> trace. If you are on Linux, maybe you are the victim of oome-killer?
> That will show in the syslog with a whole lot of output. Search syslog
> for "oom" and you will probably find it right away if that's the cause.
>
> -chris
>

Hi Chris,

Thanks for the answer.  It is running on Windows and it is running as a
service which is configured to restart if it fails. No different log files
at my knowledge except application logs.

There is 14 GB physical RAM on this server. Initial memory pool is 4 GB and
maximum memory pool is 8 GB.

Well, the only thing I can say is Tomcat is failing at some point and
shutting itself down or being shutdown or killed, I cannot say the JVM
itself gets killed.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le mer. 23 août 2023 à 13:16, Robert Turner  a écrit :

> You can try adding:
>
> -XX:+HeapDumpOnOutOfMemoryError
> -XX:HeapDumpPath=C:\HeapDump\java_pid.hprof
>
> to the Java options (in "Configure Tomcat") to capture heap dumps on out of
> memory errors (adjust path to suit your configuration)
>
> Robert
>

Hi Robert,

I will look into it. For now, I cannot modify the system easily. I need to
plan a change for this with at least a one week notice and upon approval.
Will try to include this in a forthcoming change.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Le jeu. 24 août 2023 à 02:29, Thomas Hoffmann (Speed4Trade GmbH)
 a écrit :

> Hello Daniel,
>
> > -Ursprüngliche Nachricht-
> > Von: Daniel Savard 
> > Gesendet: Mittwoch, 23. August 2023 19:03
> > An: users@tomcat.apache.org
> > Betreff: Tomcat 9.0.x on Windows crashing
> >
> > Hi everyone,
> >
> > I didn't specify the actual Tomcat version because the problem occurs
> under
> > all versions. We are running a commercial web application and all of
> sudden
> > after a while Tomcat is crashing without issuing any message. It is very
> likely
> > due to the application. But the vendor was of no help to solve this
> problem
> > which has existed for a long time. I suspect something like insufficient
> > memory allocated to the VM or something like that. Is there anything I
> can
> > do to gather more information on the root cause of this issue?
> >
> > Tomcat is running as a service and is restarted automatically if it
> crashes.
> > Again, the problem is very unlikely to be with Tomcat itself, but the
> tuning of
> > the VM.
> >
> > -
> > Daniel Savard
>
> You can also watch out for a file named hs_err_pid
> If the JVM is crashing hard, it usually produces this file somewhere in
> the Tomcat folder.
>
> Greetings,
> Thomas
>

Thanks for the tip, there is no such file in the whole filesystem. So, the
JVM isn't crashing, but Tomcat is crashing.

-
Daniel Savard

Re: Tomcat 9.0.x on Windows crashing

[Christopher Schultz]

Daniel,

On 8/23/23 13:03, Daniel Savard wrote:

I didn't specify the actual Tomcat version because the problem occurs under
all versions. We are running a commercial web application and all of sudden
after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve this
problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself, but
the tuning of the VM.


What kind of environment (e.g. Windows vs UNIX, etc.)? What is running 
the service? Are there log files for the service which are different 
than usual (e.g. syslog vs catalina.out)?


What are your memory settings, and how much physical RAM do you have?

It's unlikely that the JVM is just disappearing without leaving any 
trace. If you are on Linux, maybe you are the victim of oome-killer? 
That will show in the syslog with a whole lot of output. Search syslog 
for "oom" and you will probably find it right away if that's the cause.


-chris

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

AW: Tomcat 9.0.x on Windows crashing

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Daniel,

> -Ursprüngliche Nachricht-
> Von: Daniel Savard 
> Gesendet: Mittwoch, 23. August 2023 19:03
> An: users@tomcat.apache.org
> Betreff: Tomcat 9.0.x on Windows crashing
> 
> Hi everyone,
> 
> I didn't specify the actual Tomcat version because the problem occurs under
> all versions. We are running a commercial web application and all of sudden
> after a while Tomcat is crashing without issuing any message. It is very 
> likely
> due to the application. But the vendor was of no help to solve this problem
> which has existed for a long time. I suspect something like insufficient
> memory allocated to the VM or something like that. Is there anything I can
> do to gather more information on the root cause of this issue?
> 
> Tomcat is running as a service and is restarted automatically if it crashes.
> Again, the problem is very unlikely to be with Tomcat itself, but the tuning 
> of
> the VM.
> 
> -
> Daniel Savard

You can also watch out for a file named hs_err_pid 
If the JVM is crashing hard, it usually produces this file somewhere in the 
Tomcat folder.

Greetings,
Thomas

Re: Tomcat 9.0.x on Windows crashing

[Robert Turner]

You can try adding:

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=C:\HeapDump\java_pid.hprof

to the Java options (in "Configure Tomcat") to capture heap dumps on out of
memory errors (adjust path to suit your configuration)

Robert


On Wed, Aug 23, 2023 at 1:03 PM Daniel Savard 
wrote:

> Hi everyone,
>
> I didn't specify the actual Tomcat version because the problem occurs under
> all versions. We are running a commercial web application and all of sudden
> after a while Tomcat is crashing without issuing any message. It is very
> likely due to the application. But the vendor was of no help to solve this
> problem which has existed for a long time. I suspect something like
> insufficient memory allocated to the VM or something like that. Is there
> anything I can do to gather more information on the root cause of this
> issue?
>
> Tomcat is running as a service and is restarted automatically if it
> crashes. Again, the problem is very unlikely to be with Tomcat itself, but
> the tuning of the VM.
>
> -
> Daniel Savard
>

Tomcat 9.0.x on Windows crashing

[Daniel Savard]

Hi everyone,

I didn't specify the actual Tomcat version because the problem occurs under
all versions. We are running a commercial web application and all of sudden
after a while Tomcat is crashing without issuing any message. It is very
likely due to the application. But the vendor was of no help to solve this
problem which has existed for a long time. I suspect something like
insufficient memory allocated to the VM or something like that. Is there
anything I can do to gather more information on the root cause of this
issue?

Tomcat is running as a service and is restarted automatically if it
crashes. Again, the problem is very unlikely to be with Tomcat itself, but
the tuning of the VM.

-
Daniel Savard

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Mark Thomas]

On 23/12/2022 03:28, Tim N wrote:

Do you think this thread is useful info for any Tomcat-embedded Java 17
migration guide/how-to? I'm happy to tidy it up and contribute if there's
an official Tomcat-embedded place for it.


It is on the mailing list so it shoudl alreayd be findable. The wiki is 
probably the place for this.



The Java code looks good to me. The calls to
SecurityClassLoad.securityClassLoad() and Service.setParentClassLoader()
may be unnecessary


Looks like I can ditch the SecurityClassLoad.securityClassLoad() call, but
without the Service.setParentClassLoader() call I get classloading errors,





Do you think I need to look into that more, or does it make sense that the
Service.setParentClassLoader() prevents this?


It makes sense. Keep the call.

Mark

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

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

> This should be unnecessary. The classes in that package should be
> included in tomcat-embed-core

Nice - thanks. I was reading and using the catalina code, but after
trimming down my code it no longer needs that dependency.

Do you think this thread is useful info for any Tomcat-embedded Java 17
migration guide/how-to? I'm happy to tidy it up and contribute if there's
an official Tomcat-embedded place for it.

> The Java code looks good to me. The calls to
> SecurityClassLoad.securityClassLoad() and Service.setParentClassLoader()
> may be unnecessary

Looks like I can ditch the SecurityClassLoad.securityClassLoad() call, but
without the Service.setParentClassLoader() call I get classloading errors,
specifically:
Dec 23, 2022 1:47:00 PM org.apache.catalina.core.StandardContext
listenerStart
SEVERE: Error configuring application listener of class
[org.springframework.web.context.request.RequestContextListener]
java.lang.ClassNotFoundException:
org.springframework.web.context.request.RequestContextListener
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1412)
at
org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1220)
at
org.apache.catalina.core.DefaultInstanceManager.loadClass(DefaultInstanceManager.java:534)
at
org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:515)
at
org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:149)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4687)
at
org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5222)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
at
java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
at
org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
at
org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
at
java.base/java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:264)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java)
at
org.apache.tomcat.util.threads.InlineExecutorService.execute(InlineExecutorService.java:75)
at
java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:145)
at
org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
at
org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at
org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
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.Tomcat.start(Tomcat.java:486)

Do you think I need to look into that more, or does it make sense that the
Service.setParentClassLoader() prevents this?



On Thu, Dec 22, 2022 at 9:49 PM Mark Thomas  wrote:

> On 21/12/2022 22:37, Tim N wrote:
> > This was fixed by adding "--add-opens=java.base/java.lang=ALL-UNNAMED".
> Now
> > all applications are running, and various other issues have been fixed by
> > other "--add-opens" arguments. So these and the last couple of issues are
> > related to Java 17 and not the classloader code above.
> >
> > Can a Tomcat expert comment on the approach and code to customise the
> > classpath as per the thread topic - I'll repeat here for clarity:
> > Add Dependency:
> >
> > 
> >  org.apache.tomcat
> >  tomcat-catalina
> >  ${tomcat.version}
> > 
>
> This should be unnecessary. The classes in that package should be
> included in tomcat-embed-core
>
>
> > Java
>
> 
>
> The Java code looks good to me. The calls to
> SecurityClassLoad.securityClassLoad() and Service.setParentClassLoader()
> may be unnecessary but I don't think they'll cause any harm.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Mark Thomas]

On 21/12/2022 22:37, Tim N wrote:

This was fixed by adding "--add-opens=java.base/java.lang=ALL-UNNAMED". Now
all applications are running, and various other issues have been fixed by
other "--add-opens" arguments. So these and the last couple of issues are
related to Java 17 and not the classloader code above.

Can a Tomcat expert comment on the approach and code to customise the
classpath as per the thread topic - I'll repeat here for clarity:
Add Dependency:


 org.apache.tomcat
 tomcat-catalina
 ${tomcat.version}



This should be unnecessary. The classes in that package should be 
included in tomcat-embed-core




Java




The Java code looks good to me. The calls to 
SecurityClassLoad.securityClassLoad() and Service.setParentClassLoader() 
may be unnecessary but I don't think they'll cause any harm.


Mark

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

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

curityClassLoad(myClassLoader);
>>> ...
>>> Tomcat tomcat = new Tomcat();
>>> tomcat.getService().setParentClassLoader(myClassLoader);
>>>
>>> And am currently getting this:
>>> java.util.concurrent.ExecutionException:
>>> org.apache.catalina.LifecycleException: Failed to start component
>>> [StandardEngine[Tomcat].StandardHost[localhost].StandardContext[]]
>>> 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:923)
>>> at
>>> org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:835)
>>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>> at
>>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1393)
>>> at
>>> org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1383)
>>> 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:145)
>>> at
>>> org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916)
>>> at
>>> org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:265)
>>> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>> at
>>> org.apache.catalina.core.StandardService.startInternal(StandardService.java:430)
>>> 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.Tomcat.start(Tomcat.java:486)
>>>
>>> So the code looks closer to working, but still something major wrong.
>>>
>>> On Wed, Dec 21, 2022 at 11:02 AM Tim N  wrote:
>>>
>>>> > The custom class loader approach described in one of the answers is a
>>>> > viable option.
>>>>
>>>> Thanks.
>>>>
>>>> > No. The same class loader hierarchy isn't constructed when running in
>>>> > embedded mode.
>>>>
>>>> It looks like I would need to replicate all the classloading
>>>> capabilities of Tomcat (e.g. loading classes from files and JARs). Any tips
>>>> for implementing this?
>>>>
>>>> It looks like the Tomcat classloader code is available via
>>>> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina.
>>>> This isn't a tomcat-embedded module, but looks like it might be compatible.
>>>> Could these classes be used to achieve what I'm after? If I could get this
>>>> working, I could maybe contribute back with "how-to" documentation.
>>>> Thoughts?
>>>>
>>>> Also, how do I make embedded Tomcat use my classloader?
>>>>
>>>>
>>>> On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas  wrote:
>>>>
>>>>> On 14/12/2022 03:20, Tim N wrote:
>>>>> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
>>>>> > infamous compatibility issue with ClassLoader.getSystemClassLoader
>>>>> when
>>>>> > upgrading from Java 8 to Java 17.
>>>>> > See
>>>>> >
>>>>> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
>>>>> > for a good summary.
>>>>>
>>>>> The custom class loader approach described in one of the answers is a
>>>>> viable option.
>>>>>
>>>>> > Is it possible to utilise and modify the Tomcat classloader
>>>>> hierarchy for
>>>>> > embedded Tomcat to add to the classpath, specifically:
>>>>> >   - Add some shared libraries as done with the 'shared.loader' for
>>>>> Tomcat
>>>>> > for production and development environments
>>>>>
>>>>> No. The same class loader hierarchy isn't constructed when running in
>>>>> embedded mode.
>>>>>
>>>>> >   - Add another module's classes to the classpath for a web-app for
>>>>> > development environment only (e.g. add
>>>>> "../sub-module/target/classes" to
>>>>> > classpath)
>>>>>
>>>>> Yes. Each web application still retains its own class loader. You
>>>>> configure the web application resources to map static resources, JARs
>>>>> and/or directories of classes to the right place in your web app.
>>>>>
>>>>> For example (totally untested but should give you the idea):
>>>>>
>>>>> Tomcat tomcat = new Tomcat();
>>>>> Context context = tomcat.addContext("", "/some/path");
>>>>> WebResourceRoot root = context.getResources();
>>>>> DirResourceSet extraJARs = new DirResourceSet(root,
>>>>>  "/WEB-INF/lib", "/path/to/extra/jars", "");
>>>>> root.addPostResources(extraJARs);
>>>>>
>>>>> > In Java 8 I can achieve this by calling 'addURL' on
>>>>> 'URLClassLoader', but
>>>>> > that is no longer possible in Java 9+.
>>>>> >
>>>>> > Is there any official documentation for this?
>>>>>
>>>>> The docs for configuring this in context.xml are here:
>>>>>
>>>>> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>>>>>
>>>>> Javadoc for doing it directly is here:
>>>>>
>>>>>
>>>>> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>>>>>
>>>>> HTH,
>>>>>
>>>>> Mark
>>>>> >
>>>>>
>>>>> -
>>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>>
>>>>>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

t; at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>> at org.apache.catalina.startup.Tomcat.start(Tomcat.java:486)
>>
>> So the code looks closer to working, but still something major wrong.
>>
>> On Wed, Dec 21, 2022 at 11:02 AM Tim N  wrote:
>>
>>> > The custom class loader approach described in one of the answers is a
>>> > viable option.
>>>
>>> Thanks.
>>>
>>> > No. The same class loader hierarchy isn't constructed when running in
>>> > embedded mode.
>>>
>>> It looks like I would need to replicate all the classloading
>>> capabilities of Tomcat (e.g. loading classes from files and JARs). Any tips
>>> for implementing this?
>>>
>>> It looks like the Tomcat classloader code is available via
>>> https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina.
>>> This isn't a tomcat-embedded module, but looks like it might be compatible.
>>> Could these classes be used to achieve what I'm after? If I could get this
>>> working, I could maybe contribute back with "how-to" documentation.
>>> Thoughts?
>>>
>>> Also, how do I make embedded Tomcat use my classloader?
>>>
>>>
>>> On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas  wrote:
>>>
>>>> On 14/12/2022 03:20, Tim N wrote:
>>>> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
>>>> > infamous compatibility issue with ClassLoader.getSystemClassLoader
>>>> when
>>>> > upgrading from Java 8 to Java 17.
>>>> > See
>>>> >
>>>> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
>>>> > for a good summary.
>>>>
>>>> The custom class loader approach described in one of the answers is a
>>>> viable option.
>>>>
>>>> > Is it possible to utilise and modify the Tomcat classloader hierarchy
>>>> for
>>>> > embedded Tomcat to add to the classpath, specifically:
>>>> >   - Add some shared libraries as done with the 'shared.loader' for
>>>> Tomcat
>>>> > for production and development environments
>>>>
>>>> No. The same class loader hierarchy isn't constructed when running in
>>>> embedded mode.
>>>>
>>>> >   - Add another module's classes to the classpath for a web-app for
>>>> > development environment only (e.g. add "../sub-module/target/classes"
>>>> to
>>>> > classpath)
>>>>
>>>> Yes. Each web application still retains its own class loader. You
>>>> configure the web application resources to map static resources, JARs
>>>> and/or directories of classes to the right place in your web app.
>>>>
>>>> For example (totally untested but should give you the idea):
>>>>
>>>> Tomcat tomcat = new Tomcat();
>>>> Context context = tomcat.addContext("", "/some/path");
>>>> WebResourceRoot root = context.getResources();
>>>> DirResourceSet extraJARs = new DirResourceSet(root,
>>>>  "/WEB-INF/lib", "/path/to/extra/jars", "");
>>>> root.addPostResources(extraJARs);
>>>>
>>>> > In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader',
>>>> but
>>>> > that is no longer possible in Java 9+.
>>>> >
>>>> > Is there any official documentation for this?
>>>>
>>>> The docs for configuring this in context.xml are here:
>>>>
>>>> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>>>>
>>>> Javadoc for doing it directly is here:
>>>>
>>>>
>>>> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>>>>
>>>> HTH,
>>>>
>>>> Mark
>>>> >
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

 Could these classes be used to achieve what I'm after? If I could get this
>>> working, I could maybe contribute back with "how-to" documentation.
>>> Thoughts?
>>>
>>> Also, how do I make embedded Tomcat use my classloader?
>>>
>>>
>>> On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas  wrote:
>>>
>>>> On 14/12/2022 03:20, Tim N wrote:
>>>> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
>>>> > infamous compatibility issue with ClassLoader.getSystemClassLoader
>>>> when
>>>> > upgrading from Java 8 to Java 17.
>>>> > See
>>>> >
>>>> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
>>>> > for a good summary.
>>>>
>>>> The custom class loader approach described in one of the answers is a
>>>> viable option.
>>>>
>>>> > Is it possible to utilise and modify the Tomcat classloader hierarchy
>>>> for
>>>> > embedded Tomcat to add to the classpath, specifically:
>>>> >   - Add some shared libraries as done with the 'shared.loader' for
>>>> Tomcat
>>>> > for production and development environments
>>>>
>>>> No. The same class loader hierarchy isn't constructed when running in
>>>> embedded mode.
>>>>
>>>> >   - Add another module's classes to the classpath for a web-app for
>>>> > development environment only (e.g. add "../sub-module/target/classes"
>>>> to
>>>> > classpath)
>>>>
>>>> Yes. Each web application still retains its own class loader. You
>>>> configure the web application resources to map static resources, JARs
>>>> and/or directories of classes to the right place in your web app.
>>>>
>>>> For example (totally untested but should give you the idea):
>>>>
>>>> Tomcat tomcat = new Tomcat();
>>>> Context context = tomcat.addContext("", "/some/path");
>>>> WebResourceRoot root = context.getResources();
>>>> DirResourceSet extraJARs = new DirResourceSet(root,
>>>>  "/WEB-INF/lib", "/path/to/extra/jars", "");
>>>> root.addPostResources(extraJARs);
>>>>
>>>> > In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader',
>>>> but
>>>> > that is no longer possible in Java 9+.
>>>> >
>>>> > Is there any official documentation for this?
>>>>
>>>> The docs for configuring this in context.xml are here:
>>>>
>>>> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>>>>
>>>> Javadoc for doing it directly is here:
>>>>
>>>>
>>>> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>>>>
>>>> HTH,
>>>>
>>>> Mark
>>>> >
>>>>
>>>> -
>>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>>
>>>>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

ClassLoader when
>>> > upgrading from Java 8 to Java 17.
>>> > See
>>> >
>>> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
>>> > for a good summary.
>>>
>>> The custom class loader approach described in one of the answers is a
>>> viable option.
>>>
>>> > Is it possible to utilise and modify the Tomcat classloader hierarchy
>>> for
>>> > embedded Tomcat to add to the classpath, specifically:
>>> >   - Add some shared libraries as done with the 'shared.loader' for
>>> Tomcat
>>> > for production and development environments
>>>
>>> No. The same class loader hierarchy isn't constructed when running in
>>> embedded mode.
>>>
>>> >   - Add another module's classes to the classpath for a web-app for
>>> > development environment only (e.g. add "../sub-module/target/classes"
>>> to
>>> > classpath)
>>>
>>> Yes. Each web application still retains its own class loader. You
>>> configure the web application resources to map static resources, JARs
>>> and/or directories of classes to the right place in your web app.
>>>
>>> For example (totally untested but should give you the idea):
>>>
>>> Tomcat tomcat = new Tomcat();
>>> Context context = tomcat.addContext("", "/some/path");
>>> WebResourceRoot root = context.getResources();
>>> DirResourceSet extraJARs = new DirResourceSet(root,
>>>  "/WEB-INF/lib", "/path/to/extra/jars", "");
>>> root.addPostResources(extraJARs);
>>>
>>> > In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader',
>>> but
>>> > that is no longer possible in Java 9+.
>>> >
>>> > Is there any official documentation for this?
>>>
>>> The docs for configuring this in context.xml are here:
>>>
>>> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>>>
>>> Javadoc for doing it directly is here:
>>>
>>>
>>> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>>>
>>> HTH,
>>>
>>> Mark
>>> >
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>>
>>>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

n still retains its own class loader. You
>> configure the web application resources to map static resources, JARs
>> and/or directories of classes to the right place in your web app.
>>
>> For example (totally untested but should give you the idea):
>>
>> Tomcat tomcat = new Tomcat();
>> Context context = tomcat.addContext("", "/some/path");
>> WebResourceRoot root = context.getResources();
>> DirResourceSet extraJARs = new DirResourceSet(root,
>>  "/WEB-INF/lib", "/path/to/extra/jars", "");
>> root.addPostResources(extraJARs);
>>
>> > In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader',
>> but
>> > that is no longer possible in Java 9+.
>> >
>> > Is there any official documentation for this?
>>
>> The docs for configuring this in context.xml are here:
>>
>> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>>
>> Javadoc for doing it directly is here:
>>
>>
>> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>>
>> HTH,
>>
>> Mark
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

> The custom class loader approach described in one of the answers is a
> viable option.

Thanks.

> No. The same class loader hierarchy isn't constructed when running in
> embedded mode.

It looks like I would need to replicate all the classloading capabilities
of Tomcat (e.g. loading classes from files and JARs). Any tips for
implementing this?

It looks like the Tomcat classloader code is available via
https://mvnrepository.com/artifact/org.apache.tomcat/tomcat-catalina. This
isn't a tomcat-embedded module, but looks like it might be compatible.
Could these classes be used to achieve what I'm after? If I could get this
working, I could maybe contribute back with "how-to" documentation.
Thoughts?

Also, how do I make embedded Tomcat use my classloader?


On Wed, Dec 14, 2022 at 9:19 PM Mark Thomas  wrote:

> On 14/12/2022 03:20, Tim N wrote:
> > I'm currently using embedded Tomcat 9.0.68 and have encountered the
> > infamous compatibility issue with ClassLoader.getSystemClassLoader when
> > upgrading from Java 8 to Java 17.
> > See
> >
> https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
> > for a good summary.
>
> The custom class loader approach described in one of the answers is a
> viable option.
>
> > Is it possible to utilise and modify the Tomcat classloader hierarchy for
> > embedded Tomcat to add to the classpath, specifically:
> >   - Add some shared libraries as done with the 'shared.loader' for Tomcat
> > for production and development environments
>
> No. The same class loader hierarchy isn't constructed when running in
> embedded mode.
>
> >   - Add another module's classes to the classpath for a web-app for
> > development environment only (e.g. add "../sub-module/target/classes" to
> > classpath)
>
> Yes. Each web application still retains its own class loader. You
> configure the web application resources to map static resources, JARs
> and/or directories of classes to the right place in your web app.
>
> For example (totally untested but should give you the idea):
>
> Tomcat tomcat = new Tomcat();
> Context context = tomcat.addContext("", "/some/path");
> WebResourceRoot root = context.getResources();
> DirResourceSet extraJARs = new DirResourceSet(root,
>  "/WEB-INF/lib", "/path/to/extra/jars", "");
> root.addPostResources(extraJARs);
>
> > In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader', but
> > that is no longer possible in Java 9+.
> >
> > Is there any official documentation for this?
>
> The docs for configuring this in context.xml are here:
>
> https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html
>
> Javadoc for doing it directly is here:
>
>
> https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html
>
> HTH,
>
> Mark
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Mark Thomas]

On 14/12/2022 03:20, Tim N wrote:

I'm currently using embedded Tomcat 9.0.68 and have encountered the
infamous compatibility issue with ClassLoader.getSystemClassLoader when
upgrading from Java 8 to Java 17.
See
https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
for a good summary.


The custom class loader approach described in one of the answers is a 
viable option.



Is it possible to utilise and modify the Tomcat classloader hierarchy for
embedded Tomcat to add to the classpath, specifically:
  - Add some shared libraries as done with the 'shared.loader' for Tomcat
for production and development environments


No. The same class loader hierarchy isn't constructed when running in 
embedded mode.



  - Add another module's classes to the classpath for a web-app for
development environment only (e.g. add "../sub-module/target/classes" to
classpath)


Yes. Each web application still retains its own class loader. You 
configure the web application resources to map static resources, JARs 
and/or directories of classes to the right place in your web app.


For example (totally untested but should give you the idea):

Tomcat tomcat = new Tomcat();
Context context = tomcat.addContext("", "/some/path");
WebResourceRoot root = context.getResources();
DirResourceSet extraJARs = new DirResourceSet(root,
"/WEB-INF/lib", "/path/to/extra/jars", "");
root.addPostResources(extraJARs);


In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader', but
that is no longer possible in Java 9+.

Is there any official documentation for this?


The docs for configuring this in context.xml are here:

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

Javadoc for doing it directly is here:

https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/catalina/webresources/package-summary.html

HTH,

Mark




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

Embedded Tomcat 9.0.x Classpath Modification Migrating From Java 8 to 17

[Tim N]

I'm currently using embedded Tomcat 9.0.68 and have encountered the
infamous compatibility issue with ClassLoader.getSystemClassLoader when
upgrading from Java 8 to Java 17.
See
https://stackoverflow.com/questions/46694600/java-9-compatability-issue-with-classloader-getsystemclassloader
for a good summary.

Is it possible to utilise and modify the Tomcat classloader hierarchy for
embedded Tomcat to add to the classpath, specifically:
 - Add some shared libraries as done with the 'shared.loader' for Tomcat
for production and development environments
 - Add another module's classes to the classpath for a web-app for
development environment only (e.g. add "../sub-module/target/classes" to
classpath)

In Java 8 I can achieve this by calling 'addURL' on 'URLClassLoader', but
that is no longer possible in Java 9+.

Is there any official documentation for this?

Re: Tomcat 9.0.N SimpleTcpCluster Max Cluster Sizing

[Mark Thomas]

On 12/12/2022 01:18, Tim N wrote:

 From the official documentation
"The all-to-all replication is an algorithm that is only efficient when the
clusters are small. For larger clusters, you should use the BackupManager"

Any ideas on what the limit is or how to measure it? Any good articles?


It is one of those how long is a piece of string questions.

I suggest looking at the series of clustering presentations I gave 
either in 2015 or 2017. The 2017 ones have audio.


https://tomcat.apache.org/presentations.html

The short version is that with the delta manager cluster traffic grows 
with the square of the number of nodes. With the backup manager the 
growth is linear. From your current number of nodes and current 
clustering traffic, you should be able to figure our a rough limit.


If forced to pick a number without any clustering traffic data, I 
usually suggest 4 nodes is the point to switch to the backup manager.


Mark

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

Re: Tomcat 9.0.N Upgrading Minor Version In A Cluster

[Mark Thomas]

On 12/12/2022 01:16, Tim N wrote:

Will session fail-over work b/w minor versions? i.e. can you cycle through
upgrading Tomcat in a cluster from say 9.0.67 to 9.0.68?


Generally, yes. But always check the change log and the migration guide 
in case we had to make a change that places some sort of limitation on that.



Also, is there any official documentation on this?


Upgrading or the compatibility?

Some for the first. Nothing I can think of for the second.

Mark

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

Tomcat 9.0.N SimpleTcpCluster Max Cluster Sizing

[Tim N]

>From the official documentation
"The all-to-all replication is an algorithm that is only efficient when the
clusters are small. For larger clusters, you should use the BackupManager"

Any ideas on what the limit is or how to measure it? Any good articles?

Tomcat 9.0.N Upgrading Minor Version In A Cluster

[Tim N]

Will session fail-over work b/w minor versions? i.e. can you cycle through
upgrading Tomcat in a cluster from say 9.0.67 to 9.0.68? Also, is there any
official documentation on this?

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Christopher Schultz]

Shawn,

On 4/29/22 18:18, Shawn Heisey wrote:
Based on what I have been able to figure out, I think it's probably your 
cipher list.  If you are using the standard Java TLS and not the tomcat 
native library that uses openssl, then your cipher list is unlikely to 
work -- those look like openssl cipher names, and Java uses different 
names.


Tomcat can accept cipher suite names using either OpenSSL or JSSE naming 
conventions.


-chris

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

AW: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Shawn Heisey 
> Gesendet: Samstag, 30. April 2022 00:18
> An: users@tomcat.apache.org
> Betreff: Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x
> 
> On 4/29/22 12:14, Kaushal Shriyan wrote:
> > Thanks Peter for the link and it worked like a charm. I am running the
> > tomcat version 9.0.56 on CentOS Linux release 7.9.2009 (Core). I have
> > enabled the TLSv1.3 protocol as per the below block but when I ran the
> > scan https://www.ssllabs.com/ssltest/analyze.html, It says *TLS 1.3 ->
> > No* as per the below scan results.
> >
> >  >                connectionTimeout="2"
> >                SSLEnabled="true"  scheme="https"
> > ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-
> SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-
> SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-
> POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384"
> > keystoreFile="ssl/hsbcconsent.jks" keystorePass="tomcat"
> > clientAuth="false" disableSessionTickets="true"
> > honorCipherOrder="true" *SSLProtocol="TLSv1.2+TLSv1.3"*
> >                redirectPort="8443" />
> 
> I can think of two possible reasons for a problem like this.
> 
> 1. Your cipher list isn't compatible with TLS 1.3.
> 2. You're not running a new enough Java version. (8u261 b12 minimum)
> 
> Based on what I have been able to figure out, I think it's probably your 
> cipher
> list.  If you are using the standard Java TLS and not the tomcat native 
> library
> that uses openssl, then your cipher list is unlikely to work -- those look 
> like
> openssl cipher names, and Java uses different names.
> 
> I think this cipher list might get you TLS 1.2 and 1.3 support with Java:
> 
> TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_12
> 8_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECD
> HE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA2
> 0_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
> :TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_
> AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TL
> S_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
> 
> To get that list, I converted the cipher list I use in haproxy, which uses
> openssl for tls, using the info found here:
> 
> https://stackoverflow.com/a/32654075/2665648
> 
> Thanks,
> Shawn
> 
> 

That's how I configured the connector and it is using TLS 1.3








A good source for a hardened configuration is also:
https://success.qualys.com/discussions/s/question/0D52L6230HeSAI/a-grade-for-tomcat10
  

Greetings, Thomas

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

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Shawn Heisey]

On 4/29/22 12:14, Kaushal Shriyan wrote:
Thanks Peter for the link and it worked like a charm. I am running the 
tomcat version 9.0.56 on CentOS Linux release 7.9.2009 (Core). I have 
enabled the TLSv1.3 protocol as per the below block but when I ran the 
scan https://www.ssllabs.com/ssltest/analyze.html, It says *TLS 1.3 -> 
No* as per the below scan results.


               SSLEnabled="true"  scheme="https" 
ciphers="ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384" 
keystoreFile="ssl/hsbcconsent.jks" keystorePass="tomcat" 
clientAuth="false" disableSessionTickets="true" 
honorCipherOrder="true" *SSLProtocol="TLSv1.2+TLSv1.3"*

               redirectPort="8443" />


I can think of two possible reasons for a problem like this.

1. Your cipher list isn't compatible with TLS 1.3.
2. You're not running a new enough Java version. (8u261 b12 minimum)

Based on what I have been able to figure out, I think it's probably your 
cipher list.  If you are using the standard Java TLS and not the tomcat 
native library that uses openssl, then your cipher list is unlikely to 
work -- those look like openssl cipher names, and Java uses different names.


I think this cipher list might get you TLS 1.2 and 1.3 support with Java:

TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

To get that list, I converted the cipher list I use in haproxy, which 
uses openssl for tls, using the info found here:


https://stackoverflow.com/a/32654075/2665648

Thanks,
Shawn


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

Re: AW: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Christopher Schultz]

Thomas,

On 4/29/22 02:44, Thomas Hoffmann (Speed4Trade GmbH) wrote:

-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Freitag, 29. April 2022 01:10
An: users@tomcat.apache.org
Betreff: Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

Kaushal,

On 4/28/22 15:37, Kaushal Shriyan wrote:

On Fri, Apr 29, 2022 at 12:44 AM Peter Chiu  wrote:


This is what I am using. Hope this helps.

https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html


Thanks Peter. Do I need to run tomcat on port 443 or 8443 to enable
HTTP Strict Transport Security (HSTS). I will be unable to run tomcat
service on port 443 as it is a privileged port for root user only.
Currently I am running tomcat service as tomcat user on port 8080.


You must use HTTPS to connect to a server in order for the HSTS header to be
respected.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-
Transport-Security

"
Note: The Strict-Transport-Security header is ignored by the browser when
your site is accessed using HTTP; this is because an attacker may intercept
HTTP connections and inject the header or remove it. When your site is
accessed over HTTPS with no certificate errors, the browser knows your site
is HTTPS capable and will honor the Strict-Transport-Security header.
"

Is your server available via https:// ? If you are running on port 80, that
doesn't tell us if it's encrypted.

If you are enabling HSTS, how do you expect users to connect to your service
if you are running non-secure HTTP on port 8080?

-chris



Hello,
according to 
https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/master/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
the headers are set, if request.isSecure is set to true.


Sure, but the browser will ignore it if not served over HTTPS. It's 
possible to trick Tomcat into thinking that the connection is secure 
even when the client isn't using HTTPS.


(BTW, that's a really old source file. Here's the latest: 
https://github.com/apache/tomcat/blob/9.0.x/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java#L105)



So it depends on  within the server.xml
If behind a proxy with SSL Offloading, this flag can also be set on a plain 
http connection.


Yup.

-chris

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

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Kaushal Shriyan]

Thanks Peter for the link and it worked like a charm. I am running the
tomcat version 9.0.56 on CentOS Linux release 7.9.2009 (Core). I have
enabled the TLSv1.3 protocol as per the below block but when I ran the scan
https://www.ssllabs.com/ssltest/analyze.html, It says *TLS 1.3 -> No* as
per the below scan results.



https://github.com/drwetter/testssl.sh

./testssl.sh --htmlfile
testapp-consent-testpreprod.testapicraft.com.29042022.html
testapp-consent-testpreprod.testapicraft.com


###
testssl.sh   3.1dev from https://testssl.sh/dev/

  This program is free software. Distribution and
 modification under GPLv2 permitted.
  USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

   Please file bugs @ https://testssl.sh/bugs/

###

 Using "LibreSSL 2.8.3" [~69 ciphers]
 on DACADMINs-MacBook-Pro:/usr/bin/openssl
 (built: "date not available", platform: "information not available")


 Start 2022-04-29 19:02:41-->> 35.210.220.115:443 (
testapp-consent-testpreprod.testapicraft.com) <<--

 Service detected:   HTTP


 Testing protocols via sockets except NPN+ALPN

 SSLv2  not offered (OK)
 SSLv3  not offered (OK)
 TLS 1  not offered
 TLS 1.1not offered
 TLS 1.2offered (OK)
 *TLS 1.3not offered and downgraded to a weaker protocol*
 NPN/SPDY   Local problem: /usr/bin/openssl doesn't support NPN/SPDY
 ALPN/HTTP2 not offered

[image: image.png]

Am I missing anything in the /opt/tomcat9/conf/server.xml file? Please
comment and guide me. Thanks in advance

Best Regards,

Kaushal

On Fri, Apr 29, 2022 at 12:15 PM Thomas Hoffmann (Speed4Trade GmbH)
 wrote:

>
>
> > -Ursprüngliche Nachricht-
> > Von: Christopher Schultz 
> > Gesendet: Freitag, 29. April 2022 01:10
> > An: users@tomcat.apache.org
> > Betreff: Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x
> >
> > Kaushal,
> >
> > On 4/28/22 15:37, Kaushal Shriyan wrote:
> > > On Fri, Apr 29, 2022 at 12:44 AM Peter Chiu  wrote:
> > >
> > >> This is what I am using. Hope this helps.
> > >>
> > >> https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html
> > >
> > > Thanks Peter. Do I need to run tomcat on port 443 or 8443 to enable
> > > HTTP Strict Transport Security (HSTS). I will be unable to run tomcat
> > > service on port 443 as it is a privileged port for root user only.
> > > Currently I am running tomcat service as tomcat user on port 8080.
> >
> > You must use HTTPS to connect to a server in order for the HSTS header
> to be
> > respected.
> >
> > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-
> > Transport-Security
> >
> > "
> > Note: The Strict-Transport-Security header is ignored by the browser when
> > your site is accessed using HTTP; this is because an attacker may
> intercept
> > HTTP connections and inject the header or remove it. When your site is
> > accessed over HTTPS with no certificate errors, the browser knows your
> site
> > is HTTPS capable and will honor the Strict-Transport-Security header.
> > "
> >
> > Is your server available via https:// ? If you are running on port 80,
> that
> > doesn't tell us if it's encrypted.
> >
> > If you are enabling HSTS, how do you expect users to connect to your
> service
> > if you are running non-secure HTTP on port 8080?
> >
> > -chris
> >
>
> Hello,
> according to
> https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/master/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
> the headers are set, if request.isSecure is set to true.
>
> So it depends on  within the server.xml
> If behind a proxy with SSL Offloading, this flag can also be set on a
> plain http connection.
>
> Greetings,
> Thomas
>

AW: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Thomas Hoffmann (Speed4Trade GmbH)]

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Freitag, 29. April 2022 01:10
> An: users@tomcat.apache.org
> Betreff: Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x
> 
> Kaushal,
> 
> On 4/28/22 15:37, Kaushal Shriyan wrote:
> > On Fri, Apr 29, 2022 at 12:44 AM Peter Chiu  wrote:
> >
> >> This is what I am using. Hope this helps.
> >>
> >> https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html
> >
> > Thanks Peter. Do I need to run tomcat on port 443 or 8443 to enable
> > HTTP Strict Transport Security (HSTS). I will be unable to run tomcat
> > service on port 443 as it is a privileged port for root user only.
> > Currently I am running tomcat service as tomcat user on port 8080.
> 
> You must use HTTPS to connect to a server in order for the HSTS header to be
> respected.
> 
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-
> Transport-Security
> 
> "
> Note: The Strict-Transport-Security header is ignored by the browser when
> your site is accessed using HTTP; this is because an attacker may intercept
> HTTP connections and inject the header or remove it. When your site is
> accessed over HTTPS with no certificate errors, the browser knows your site
> is HTTPS capable and will honor the Strict-Transport-Security header.
> "
> 
> Is your server available via https:// ? If you are running on port 80, that
> doesn't tell us if it's encrypted.
> 
> If you are enabling HSTS, how do you expect users to connect to your service
> if you are running non-secure HTTP on port 8080?
> 
> -chris
> 

Hello,
according to 
https://github.com/Oreste-Luci/apache-tomcat-8.0.26-src/blob/master/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
 
the headers are set, if request.isSecure is set to true.

So it depends on  within the server.xml
If behind a proxy with SSL Offloading, this flag can also be set on a plain 
http connection.

Greetings,
Thomas

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Christopher Schultz]

Kaushal,

On 4/28/22 15:37, Kaushal Shriyan wrote:

On Fri, Apr 29, 2022 at 12:44 AM Peter Chiu  wrote:


This is what I am using. Hope this helps.

https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html


Thanks Peter. Do I need to run tomcat on port 443 or 8443 to enable HTTP
Strict Transport Security (HSTS). I will be unable to run tomcat service on
port 443 as it is a privileged port for root user only. Currently I am
running tomcat service as tomcat user on port 8080.


You must use HTTPS to connect to a server in order for the HSTS header 
to be respected.


https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

"
Note: The Strict-Transport-Security header is ignored by the browser 
when your site is accessed using HTTP; this is because an attacker may 
intercept HTTP connections and inject the header or remove it. When your 
site is accessed over HTTPS with no certificate errors, the browser 
knows your site is HTTPS capable and will honor the 
Strict-Transport-Security header.

"

Is your server available via https:// ? If you are running on port 80, 
that doesn't tell us if it's encrypted.


If you are enabling HSTS, how do you expect users to connect to your 
service if you are running non-secure HTTP on port 8080?


-chris

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

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Kaushal Shriyan]

On Fri, Apr 29, 2022 at 12:44 AM Peter Chiu  wrote:

> This is what I am using. Hope this helps.
>
> https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html


Thanks Peter. Do I need to run tomcat on port 443 or 8443 to enable HTTP
Strict Transport Security (HSTS). I will be unable to run tomcat service on
port 443 as it is a privileged port for root user only. Currently I am
running tomcat service as tomcat user on port 8080.

Please suggest further. Thanks in advance

Best Regards,

Kaushal

Re: Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Peter Chiu]

This is what I am using. Hope this helps.

https://orclcs.blogspot.com/2017/04/enable-hsts-in-tomcat.html

On Thu, Apr 28, 2022 at 3:11 PM Kaushal Shriyan 
wrote:

> Hi,
>
> I am running the tomcat version 9.0.56 on CentOS Linux release 7.9.2009
> (Core) and trying to configure HTTP Strict Transport Security (HSTS)
> using /opt/tomcat9/conf/web.xml
>
> # ./version.sh
> Using CATALINA_BASE:   /opt/tomcat9
> Using CATALINA_HOME:   /opt/tomcat9
> Using CATALINA_TMPDIR: /opt/tomcat9/temp
> Using JRE_HOME:
>  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-1.el7_9.x86_64
> Using CLASSPATH:
> /opt/tomcat9/bin/bootstrap.jar:/opt/tomcat9/bin/tomcat-juli.jar
> Using CATALINA_OPTS:
> Server version: Apache Tomcat/9.0.56
> Server built:   Dec 2 2021 14:30:07 UTC
> Server number:  9.0.56.0
> OS Name:Linux
> OS Version: 3.10.0-1160.62.1.el7.x86_64
> Architecture:   amd64
> JVM Version:1.8.0_322-b06
> JVM Vendor: Red Hat, Inc.
> # cat /etc/redhat-release
> CentOS Linux release 7.9.2009 (Core)
> #
>
>
> > */opt/tomcat9/conf/web.xml*
> >   httpHeaderSecurity
> >
> >
> org.apache.catalina.filters.HttpHeaderSecurityFilter
> >   true
> >   
> > hstsEnabled
> > true
> >   
> >   
> > hstsMaxAgeSeconds
> > 31536000
> >   
> >   
> > hstsIncludeSubDomains
> > true
> >   
> > 
> > 
> >   httpHeaderSecurity
> >   /*
> >   REQUEST
> > 
>
>
> When I scan the https://tomcatURL FQDN using
> https://www.ssllabs.com/ssltest/ I do not see the Strict Transport
> Security
> response header. Please guide me. Thanks in advance
>
> Best Regards,
>
> Kaushal
>

Enable HTTP Strict Transport Security (HSTS) in Tomcat 9.0.x

[Kaushal Shriyan]

Hi,

I am running the tomcat version 9.0.56 on CentOS Linux release 7.9.2009
(Core) and trying to configure HTTP Strict Transport Security (HSTS)
using /opt/tomcat9/conf/web.xml

# ./version.sh
Using CATALINA_BASE:   /opt/tomcat9
Using CATALINA_HOME:   /opt/tomcat9
Using CATALINA_TMPDIR: /opt/tomcat9/temp
Using JRE_HOME:
 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.322.b06-1.el7_9.x86_64
Using CLASSPATH:
/opt/tomcat9/bin/bootstrap.jar:/opt/tomcat9/bin/tomcat-juli.jar
Using CATALINA_OPTS:
Server version: Apache Tomcat/9.0.56
Server built:   Dec 2 2021 14:30:07 UTC
Server number:  9.0.56.0
OS Name:Linux
OS Version: 3.10.0-1160.62.1.el7.x86_64
Architecture:   amd64
JVM Version:1.8.0_322-b06
JVM Vendor: Red Hat, Inc.
# cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
#


> */opt/tomcat9/conf/web.xml*
>   httpHeaderSecurity
>
> org.apache.catalina.filters.HttpHeaderSecurityFilter
>   true
>   
> hstsEnabled
> true
>   
>   
> hstsMaxAgeSeconds
> 31536000
>   
>   
> hstsIncludeSubDomains
> true
>   
> 
> 
>   httpHeaderSecurity
>   /*
>   REQUEST
> 


When I scan the https://tomcatURL FQDN using
https://www.ssllabs.com/ssltest/ I do not see the Strict Transport Security
response header. Please guide me. Thanks in advance

Best Regards,

Kaushal

RE: Tomcat 9.0.x JDBC connection pool does not always remove abandoned connections

[Martin, Gerhardt A]

Chris, 

really appreciate you taking some time to respond. See my replies inline below.

> -Original Message-
> From: Christopher Schultz 
> Sent: Thursday, October 14, 2021 12:19 PM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.x JDBC connection pool does not always remove
> abandoned connections
> 
> Gerhardt,
> 
> On 10/12/21 13:27, Martin, Gerhardt A wrote:
> > Running Tomcat 9.0.50 on Centos 7.9.x Linux and using Tomcat JDBC
> connection pool to connect to my application's databases. My app connects to
> about a dozen read only databases and one read/write database. Here is a
> typical resource definition with tuning configurations for the pool and the
> MSSQL server JDBC driver:
> >
> >  
> Note that these are the only relevant attributes:
> 
>  > factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> 
> You are using tomcat-pool, not the default commons-dbcp.
 
100% aware of this and we plan to continue to use it.
> 
> > maxActive="20"
> > initialSize="1"
> > maxIdle="8"
> > minIdle="1"
> > maxWait="5000"
> > testOnBorrow="false"
> > testWhileIdle="false"
> > testOnConnect="false"
> > testOnReturn="false"
> > timeBetweenEvictionRunsMillis="1"
> > removeAbandonedTimeout="15"
> > removeAbandoned="true"
> > logAbandoned="false"
> > minEvictableIdleTimeMillis="90"
> > maxAge="60"
> 
> 
> 
> > Important NOTE: the framework we employ does NOT execute more than one
> > SQL statement per borrow from the connection pool. It's a constant
> > cycle of getConnection(borrow) ->execute 1
> > SQL->closeConnection(return)
> 
> That's kind of wasteful, but okay.
I agree to some extent, but we have had stable success with this inherited 
approach. Tough to change this in our current situation but I have had thoughts 
about it. 
> 
> > Why are we configured this way:
> > Ultimately we need to fail fast to avoid our APP going into death by stuck
> threads when we lose connectivity to the backend databases for a short period
> of time. ( for example a short 10 second period where the DB(s) is/are
> unreachable from the app servers).
> 
> Is this common?
 
Not common, but when it occurs it is very disruptive to our customer base, 
hence the need to improve resiliency.  
> 
> > -We want the evictor thread (Pool Cleaner) to run every 10 seconds -We
> > are only using the Pool Cleaner to clobber busy connections that have been
> running 15 seconds or more
> >NOTE: we rarely see SQL that takes longer than 2 seconds, most are
> > sub 100ms and the avg is about 4ms
> 
> Note that the connections aren't clobbered; they are simply dropped from the
> pool. The work they generated is still continuing...
> 
> > -We are not testing connections period -We want our connections
> > replaced with new fresh connections after 10 mins of use hence we set
> > maxAge=60 The connection pool settings work hand in hand with
> properties set on the SQL server JDBC driver in the URL:
> > The driver will kill any SQL that takes longer than 10 seconds
> 
> Ouch.
> 
> > -When everything else is OK, then the connection itself is returned
> > intact back to the connection pool -When the DB is unreachable, there
> > is another timer cancelQueryTimeout set to 10 seconds which is a safety 
> > valve
> for cases where the message to the DB server to cancel the SQL gracefully does
> not make it to the DB. After the cancleQueryTimeout, the client side of the
> driver gives up. This is problematic because it actually returns a bad 
> connection
> back to the connection pool.
> >
> > The combination of the connection pool settings to run the Pool cleaner 
> > every
> 10 seconds and removeAbandoned of 15 seconds should work together to
> remove any connection whose SQL execution time went past 10 seconds before
> the cancelQueryTimeout kicks in. This should prevent returning bad connections
> to the pool when bad things happen like a network switch going offline
> temporarily and dropping all packets between the app server hosting tomcat and
> the database server.
> 
> Sounds like you really just want to be validating connections, but you have
> explicitly disabled that feature. Why?
 
So we have a fairly high volume of SQL in our APPs and given our current 
borrow->execute SQL-> return situation, test on borrow or return doubles the 
number of SQL statements we run even if one of them is "SELECT 1". Our DBAs are 
not keen on

Re: Tomcat 9.0.x JDBC connection pool does not always remove abandoned connections

[Christopher Schultz]

Gerhardt,

On 10/12/21 13:27, Martin, Gerhardt A wrote:

Running Tomcat 9.0.50 on Centos 7.9.x Linux and using Tomcat JDBC connection 
pool to connect to my application's databases. My app connects to about a dozen 
read only databases and one read/write database. Here is a typical resource 
definition with tuning configurations for the pool and the MSSQL server JDBC 
driver:



Note that these are the only relevant attributes:

> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"

You are using tomcat-pool, not the default commons-dbcp.


maxActive="20"
initialSize="1"
maxIdle="8"
minIdle="1"
maxWait="5000"
testOnBorrow="false" 
testWhileIdle="false" 
testOnConnect="false" 
testOnReturn="false" 
timeBetweenEvictionRunsMillis="1"

removeAbandonedTimeout="15"
removeAbandoned="true"
logAbandoned="false"
minEvictableIdleTimeMillis="90"
maxAge="60"





Important NOTE: the framework we employ does NOT execute more than one SQL statement 
per borrow from the connection pool. It's a constant cycle of getConnection(borrow) 
->execute 1 SQL->closeConnection(return)


That's kind of wasteful, but okay.


Why are we configured this way:
Ultimately we need to fail fast to avoid our APP going into death by stuck 
threads when we lose connectivity to the backend databases for a short period 
of time. ( for example a short 10 second period where the DB(s) is/are 
unreachable from the app servers).


Is this common?


-We want the evictor thread (Pool Cleaner) to run every 10 seconds
-We are only using the Pool Cleaner to clobber busy connections that have been 
running 15 seconds or more
   NOTE: we rarely see SQL that takes longer than 2 seconds, most are sub 100ms 
and the avg is about 4ms


Note that the connections aren't clobbered; they are simply dropped from 
the pool. The work they generated is still continuing...



-We are not testing connections period
-We want our connections replaced with new fresh connections after 10 mins of 
use hence we set maxAge=60
The connection pool settings work hand in hand with properties set on the SQL 
server JDBC driver in the URL:
The driver will kill any SQL that takes longer than 10 seconds


Ouch.


-When everything else is OK, then the connection itself is returned intact back 
to the connection pool
-When the DB is unreachable, there is another timer cancelQueryTimeout set to 
10 seconds which is a safety valve for cases where the message to the DB server 
to cancel the SQL gracefully does not make it to the DB. After the
cancleQueryTimeout, the client side of the driver gives up. This is problematic 
because it actually returns a bad connection back to the connection pool.

The combination of the connection pool settings to run the Pool cleaner every 
10 seconds and removeAbandoned of 15 seconds should work together to remove any 
connection whose SQL execution time went past 10 seconds before the 
cancelQueryTimeout kicks in. This should prevent returning bad connections to 
the pool when bad things happen like a network switch going offline temporarily 
and dropping all packets between the app server hosting tomcat and the database 
server.


Sounds like you really just want to be validating connections, but you 
have explicitly disabled that feature. Why?



NOTE that for the MSSQL server driver all their timeouts default to wait indefinitely. 
This is one of the prime reasons why even short outages can kill our APP with stuck 
threads. Our Web app hits tomcat about 2000 requests per minute and each request is going 
to fire on AVG ~6 SQL statements so we are running about 12K SQL hits per minute. If we 
lose connectivity to a database for even 15 seconds without a means to fail fast we could 
easily overcome the allotted number of threads which will create a "log jam" 
that can take a very long time to recover.


Why doesn't your query-timeout handle this situation?


So I am very sorry for all this lenghty background but I thought it might help 
for readers and potential responders to know a bit about why we do what we do 
in our connection pool.

Finally now onto the problem:

I was running a load test and simulating the temporary loss of connectivity to one or 
more of the databases used in the APP and I noticed a strange behavior that does not 
align with my understanding of how Tomcat JDBC removeAbandoned works. While most of my 
database connections coming from the pool did die shortly after the simulation started 
and "failed fast" there were a few connections that actually ran for up to 5 
minutes before they terminated themselves. Given the configuration I explained I would 
have expected no database connection that was interacting with the database to live 
beyond 30 seconds. ( giving that there could be some forward/reverse lag in the evictor 
thread timing where there could be a slight chance that the first run of the evictor 
thread might not catch every connection that was at the 15 seconds mark.)


Remember that the pool won't ki

Tomcat 9.0.x JDBC connection pool does not always remove abandoned connections

[Martin, Gerhardt A]

Running Tomcat 9.0.50 on Centos 7.9.x Linux and using Tomcat JDBC connection 
pool to connect to my application's databases. My app connects to about a dozen 
read only databases and one read/write database. Here is a typical resource 
definition with tuning configurations for the pool and the MSSQL server JDBC 
driver:

 

Important NOTE: the framework we employ does NOT execute more than one SQL 
statement per borrow from the connection pool. It's a constant cycle of 
getConnection(borrow) ->execute 1 SQL->closeConnection(return) 


Why are we configured this way: 
Ultimately we need to fail fast to avoid our APP going into death by stuck 
threads when we lose connectivity to the backend databases for a short period 
of time. ( for example a short 10 second period where the DB(s) is/are 
unreachable from the app servers).   

-We want the evictor thread (Pool Cleaner) to run every 10 seconds
-We are only using the Pool Cleaner to clobber busy connections that have been 
running 15 seconds or more
  NOTE: we rarely see SQL that takes longer than 2 seconds, most are sub 100ms 
and the avg is about 4ms
-We are not testing connections period 
-We want our connections replaced with new fresh connections after 10 mins of 
use hence we set maxAge=60

The connection pool settings work hand in hand with properties set on the SQL 
server JDBC driver in the URL:
The driver will kill any SQL that takes longer than 10 seconds
-When everything else is OK, then the connection itself is returned intact back 
to the connection pool
-When the DB is unreachable, there is another timer cancelQueryTimeout set to 
10 seconds which is a safety valve for cases where the message to the DB server 
to cancel the SQL gracefully does not make it to the DB. After the
cancleQueryTimeout, the client side of the driver gives up. This is problematic 
because it actually returns a bad connection back to the connection pool. 

The combination of the connection pool settings to run the Pool cleaner every 
10 seconds and removeAbandoned of 15 seconds should work together to remove any 
connection whose SQL execution time went past 10 seconds before the 
cancelQueryTimeout kicks in. This should prevent returning bad connections to 
the pool when bad things happen like a network switch going offline temporarily 
and dropping all packets between the app server hosting tomcat and the database 
server. 

NOTE that for the MSSQL server driver all their timeouts default to wait 
indefinitely. This is one of the prime reasons why even short outages can kill 
our APP with stuck threads. Our Web app hits tomcat about 2000 requests per 
minute and each request is going to fire on AVG ~6 SQL statements so we are 
running about 12K SQL hits per minute. If we lose connectivity to a database 
for even 15 seconds without a means to fail fast we could easily overcome the 
allotted number of threads which will create a "log jam" that can take a very 
long time to recover.  

So I am very sorry for all this lenghty background but I thought it might help 
for readers and potential responders to know a bit about why we do what we do 
in our connection pool.

Finally now onto the problem: 

I was running a load test and simulating the temporary loss of connectivity to 
one or more of the databases used in the APP and I noticed a strange behavior 
that does not align with my understanding of how Tomcat JDBC removeAbandoned 
works. While most of my database connections coming from the pool did die 
shortly after the simulation started and "failed fast" there were a few 
connections that actually ran for up to 5 minutes before they terminated 
themselves. Given the configuration I explained I would have expected no 
database connection that was interacting with the database to live beyond 30 
seconds. ( giving that there could be some forward/reverse lag in the evictor 
thread timing where there could be a slight chance that the first run of the 
evictor thread might not catch every connection that was at the 15 seconds 
mark.) 

What I believe I saw in some cases was that the socket timeout that I set on 
the SQLServer JDBC driver for  300,000ms (5 mins) kicked in and read timeout 
was generated in the driver. This lead to a bad connection being returned to 
the connection pool and caused errors until the connection(s) aged out due to 
maxAge. 


Does anyone know why the Pool Cleaner would be able to run and NOT forcefully 
remove a connection from the tomcat JDBC pool that has been running more than 
configured removeAbandonedTimeout? 
I searched google and this list on MARC for any clues and I found nothing. I 
also reviewed the source code for the Tomcat JDBC module and was unable to see 
a place in the code that indicated it would not be able to clobber a running 
connection  that was borrowed from the pool.

Anyone able to help me understand what I saw in my testing? Could this be a 
Tomcat connection pool bug?


-Regards-

Gerhardt Martin | Sr. Softwa

Re: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Javateck]

Thank you Mark

Andrew

> On Oct 8, 2021, at 1:44 AM, Mark Thomas  wrote:
> 
> On 07/10/2021 22:23, Javateck wrote:
>> Hi Mark,
>> Just wondering whether we have a radar to track this, will it be in release 
>> notes for next release?
> 
> The fix is in 9.0.54 and is listed in the changelog.
> 
> Mark
> 
>> Thanks,
>> Andrew
 On Sep 27, 2021, at 8:54 AM, Mark Thomas  wrote:
>>> 
>>> On 27/09/2021 15:55, Mark Thomas wrote:
> On 27/09/2021 09:08, Goldengate liu wrote:
> Hi Mark,
> 
>I’m uploading some test files
 Thanks for the test case. I'm looking at this now.
>>> 
>>> Bug found and fixed.
>>> 
>>> One thing to note is that with chunked encoding it is possible for you to 
>>> see isReady() return true only for the subsequent read to return 0 bytes. 
>>> This happens when just (or only part of) the chunked header is available.
>>> 
>>> The sample code you provided handled this correctly.
>>> 
>>> The fix will be in the October release round. The release process for that 
>>> should hopefully start later today.
>>> 
>>> 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
> 
> 
> -
> 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: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Mark Thomas]

On 07/10/2021 22:23, Javateck wrote:

Hi Mark,

Just wondering whether we have a radar to track this, will it be in release 
notes for next release?


The fix is in 9.0.54 and is listed in the changelog.

Mark



Thanks,
Andrew


On Sep 27, 2021, at 8:54 AM, Mark Thomas  wrote:

On 27/09/2021 15:55, Mark Thomas wrote:

On 27/09/2021 09:08, Goldengate liu wrote:
Hi Mark,

I’m uploading some test files

Thanks for the test case. I'm looking at this now.


Bug found and fixed.

One thing to note is that with chunked encoding it is possible for you to see 
isReady() return true only for the subsequent read to return 0 bytes. This 
happens when just (or only part of) the chunked header is available.

The sample code you provided handled this correctly.

The fix will be in the October release round. The release process for that 
should hopefully start later today.

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




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

Re: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Javateck]

Hi Mark,

Just wondering whether we have a radar to track this, will it be in release 
notes for next release?

Thanks,
Andrew

> On Sep 27, 2021, at 8:54 AM, Mark Thomas  wrote:
> 
> On 27/09/2021 15:55, Mark Thomas wrote:
>>> On 27/09/2021 09:08, Goldengate liu wrote:
>>> Hi Mark,
>>> 
>>>I’m uploading some test files
>> Thanks for the test case. I'm looking at this now.
> 
> Bug found and fixed.
> 
> One thing to note is that with chunked encoding it is possible for you to see 
> isReady() return true only for the subsequent read to return 0 bytes. This 
> happens when just (or only part of) the chunked header is available.
> 
> The sample code you provided handled this correctly.
> 
> The fix will be in the October release round. The release process for that 
> should hopefully start later today.
> 
> 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

Re: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Javateck]

Mark,

Thank you very much for the quick fix

Andrew

> On Sep 27, 2021, at 8:54 AM, Mark Thomas  wrote:
> 
> On 27/09/2021 15:55, Mark Thomas wrote:
>>> On 27/09/2021 09:08, Goldengate liu wrote:
>>> Hi Mark,
>>> 
>>>I’m uploading some test files
>> Thanks for the test case. I'm looking at this now.
> 
> Bug found and fixed.
> 
> One thing to note is that with chunked encoding it is possible for you to see 
> isReady() return true only for the subsequent read to return 0 bytes. This 
> happens when just (or only part of) the chunked header is available.
> 
> The sample code you provided handled this correctly.
> 
> The fix will be in the October release round. The release process for that 
> should hopefully start later today.
> 
> 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

Re: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Mark Thomas]

On 27/09/2021 15:55, Mark Thomas wrote:

On 27/09/2021 09:08, Goldengate liu wrote:

Hi Mark,

   I’m uploading some test files


Thanks for the test case. I'm looking at this now.


Bug found and fixed.

One thing to note is that with chunked encoding it is possible for you 
to see isReady() return true only for the subsequent read to return 0 
bytes. This happens when just (or only part of) the chunked header is 
available.


The sample code you provided handled this correctly.

The fix will be in the October release round. The release process for 
that should hopefully start later today.


Mark

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

Re: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Mark Thomas]

On 27/09/2021 09:08, Goldengate liu wrote:

Hi Mark,

   I’m uploading some test files


Thanks for the test case. I'm looking at this now.

Mark



   Below are the steps:
1. compile GetPayloadServlet.java and put it to 
webapps/test/WEB-INF/classes/test/

2. put web.xml to webapps/test/WEB-INF/
3. start tomcat (9.0.19), I tried with 9.0.53, I got the same result
4. use HttpPostTest(I’m using Apache httpclient-4.5.1.jar, 
httpcore-4.4.4.jar), the test is sending data with chunked 
transfer-encoding, one step here
4.1. put a debug point before streamWrite at flushBuffer method in 
org.apache.http.impl.io.SessionOutputBufferImpl, the purpose is to pause 
flushing to the socket

*private* *void* flushBuffer() *throws* IOException {
*final* *int* len = *this*.buffer.length();
*if* (len > 0) {
streamWrite(*this*.buffer.buffer(), 0, len);
*this*.buffer.clear();
*this*.metrics.incrementBytesTransferred(len);
}

}

      5. put a debug point on GetPayloadServlet

@Override
public void onDataAvailable() throws IOException {
byte buffer[] = new byte[BUFFER_SIZE];
while(inputStream.isReady()) {// when isReady returns true, 
inputStream.read(buffer) is actually blocked with chunked encoding

int read = inputStream.read(buffer);
if (read < 0) {
break;
}
bos.write(buffer, 0, read);
}
}

6. we can see once SessionOutputBufferImpl.flushBuffer flushes the 
data,inputStream.read(buffer) inside GetPayloadServlet will be 
un-blocked with read


   Or am I doing something wrong? this is a basic use case.

   Thanks,
   Andrew



On Sep 22, 2021, at 1:14 AM, Mark Thomas > wrote:


On 22/09/2021 08:22, Goldengate liu wrote:

Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to 
read as non-blocking way as long as there is data ready locally by 
calling isReady method and check the ready condition before calling 
read, and read should throw IllegalStateException if called by 
caller when data is not ready


The above only applies if the servlet is in async mode. Is it?

correct, when it’s running as async mode


OK. You are going to need to provide the simplest complete example 
that demonstrates this then. Something like the source for a single 
Servlet and a curl command to send a request to it.


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

Re: Tomcat 9.0 async read becomes blocking with chunked transfer-encoding

[Goldengate liu]

Hi Mark,  I’m uploading some test files

GetPayloadServlet.java
Description: Binary data


HttpPostTest.java
Description: Binary data


web.xml
Description: XML document
  Below are the steps:	1. compile GetPayloadServlet.java and put it to webapps/test/WEB-INF/classes/test/	2. put web.xml to webapps/test/WEB-INF/	3. start tomcat (9.0.19), I tried with 9.0.53, I got the same result	4. use HttpPostTest(I’m using Apache httpclient-4.5.1.jar, httpcore-4.4.4.jar), the test is sending data with chunked transfer-encoding, one step here 		4.1. put a debug point before streamWrite at flushBuffer method in org.apache.http.impl.io.SessionOutputBufferImpl, the purpose is to pause flushing to the socket		    private void flushBuffer() throws IOException {        final int len = this.buffer.length();        if (len > 0) {            streamWrite(this.buffer.buffer(), 0, len);            this.buffer.clear();            this.metrics.incrementBytesTransferred(len);        }    }     5. put a debug point on GetPayloadServlet			@Override			public void onDataAvailable() throws IOException {byte buffer[] = new byte[BUFFER_SIZE];while(inputStream.isReady()) {// when isReady returns true, inputStream.read(buffer) is actually blocked with chunked encoding	int read = inputStream.read(buffer);	if (read < 0) {		break;	}	bos.write(buffer, 0, read);}			}	6. we can see once SessionOutputBufferImpl.flushBuffer flushes the data, inputStream.read(buffer) inside GetPayloadServlet will be un-blocked with read  Or am I doing something wrong? this is a basic use case.  Thanks,  AndrewOn Sep 22, 2021, at 1:14 AM, Mark Thomas  wrote:On 22/09/2021 08:22, Goldengate liu wrote:Hi Chris,Servlet 3.1 spec defines that ServletInputStream can be used to read as non-blocking way as long as there is data ready locally by calling isReady method and check the ready condition before calling read, and read should throw IllegalStateException if called by caller when data is not readyThe above only applies if the servlet is in async mode. Is it?correct, when it’s running as async modeOK. You are going to need to provide the simplest complete example that demonstrates this then. Something like the source for a single Servlet and a curl command to send a request to it.Mark-To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.orgFor additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 9.0 async read becomes blocking

[Mark Thomas]

On 22/09/2021 08:22, Goldengate liu wrote:

Hi Chris,
Servlet 3.1 spec defines that ServletInputStream can be used to read as 
non-blocking way as long as there is data ready locally by calling isReady 
method and check the ready condition before calling read, and read should throw 
IllegalStateException if called by caller when data is not ready


The above only applies if the servlet is in async mode. Is it?


correct, when it’s running as async mode


OK. You are going to need to provide the simplest complete example that 
demonstrates this then. Something like the source for a single Servlet 
and a curl command to send a request to it.


Mark


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

Re: Tomcat 9.0 async read becomes blocking

[Goldengate liu]

>> Hi Chris,
>> Servlet 3.1 spec defines that ServletInputStream can be used to read as 
>> non-blocking way as long as there is data ready locally by calling isReady 
>> method and check the ready condition before calling read, and read should 
>> throw IllegalStateException if called by caller when data is not ready
> 
> The above only applies if the servlet is in async mode. Is it?

correct, when it’s running as async mode 

Andrew


> On Sep 21, 2021, at 11:17 PM, Mark Thomas  wrote:
> 
> On 21/09/2021 23:01, Javateck wrote:
>> Hi Chris,
>> Servlet 3.1 spec defines that ServletInputStream can be used to read as 
>> non-blocking way as long as there is data ready locally by calling isReady 
>> method and check the ready condition before calling read, and read should 
>> throw IllegalStateException if called by caller when data is not ready
> 
> The above only applies if the servlet is in async mode. Is it?
> 
> Mark
> 
> 
>> Agree that InputStream read api is blocking by nature, but if the data is 
>> already there in local buffer, then it’s not, it’s just exposing as 
>> ServletInputStream
>> https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf
>>  
>> 
>>  
>> >  
>> >
>>> On Sep 21, 2021, at 2:26 PM, Christopher Schultz 
>>> mailto:ch...@christopherschultz.net>> wrote:
>>> 
>>> Andrew,
>>> 
>>> On 9/21/21 13:54, Javateck wrote:
 Hi,
 With NIO connector with Servlet 3.1 support, I’m registering with a 
 ReadListener, while it got the first read signal from tomcat container (I 
 tried 9.0.19 and 9.0.53), the read call is blocked after isReady returns 
 true
   if (ServletInputStream.isReady()) {
ServletInputStream.read(buffer);  // this becomes blocking
   }
 I tried with jetty, it’s working fine
 When I did the test, I was holding the sending packet from client side
 Not sure whether anyone has tried this
>>> 
>>> InputStream is always blocking.
>>> 
>>> Are you trying to use async? That's not the way to use async...
>>> 
>>> -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: Tomcat 9.0 async read becomes blocking

[Mark Thomas]

On 21/09/2021 23:01, Javateck wrote:

Hi Chris,

Servlet 3.1 spec defines that ServletInputStream can be used to read as 
non-blocking way as long as there is data ready locally by calling 
isReady method and check the ready condition before calling read, and 
read should throw IllegalStateException if called by caller when data is 
not ready


The above only applies if the servlet is in async mode. Is it?

Mark




Agree that InputStream read api is blocking by nature, but if the data 
is already there in local buffer, then it’s not, it’s just exposing as 
ServletInputStream


https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf 






On Sep 21, 2021, at 2:26 PM, Christopher Schultz 
 wrote:


Andrew,

On 9/21/21 13:54, Javateck wrote:

Hi,
With NIO connector with Servlet 3.1 support, I’m registering with a 
ReadListener, while it got the first read signal from tomcat 
container (I tried 9.0.19 and 9.0.53), the read call is blocked after 
isReady returns true

  if (ServletInputStream.isReady()) {
   ServletInputStream.read(buffer);  // this becomes blocking
  }
I tried with jetty, it’s working fine
When I did the test, I was holding the sending packet from client side
Not sure whether anyone has tried this


InputStream is always blocking.

Are you trying to use async? That's not the way to use async...

-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: Tomcat 9.0 async read becomes blocking

[Javateck]

Hi Chris,

Servlet 3.1 spec defines that ServletInputStream can be used to read as 
non-blocking way as long as there is data ready locally by calling isReady 
method and check the ready condition before calling read, and read should throw 
IllegalStateException if called by caller when data is not ready

Agree that InputStream read api is blocking by nature, but if the data is 
already there in local buffer, then it’s not, it’s just exposing as 
ServletInputStream

https://javaee.github.io/servlet-spec/downloads/servlet-3.1/Final/servlet-3_1-final.pdf




> On Sep 21, 2021, at 2:26 PM, Christopher Schultz 
>  wrote:
> 
> Andrew,
> 
>> On 9/21/21 13:54, Javateck wrote:
>> Hi,
>> With NIO connector with Servlet 3.1 support, I’m registering with a 
>> ReadListener, while it got the first read signal from tomcat container (I 
>> tried 9.0.19 and 9.0.53), the read call is blocked after isReady returns true
>>   if (ServletInputStream.isReady()) {
>>ServletInputStream.read(buffer);  // this becomes blocking
>>   }
>> I tried with jetty, it’s working fine
>> When I did the test, I was holding the sending packet from client side
>> Not sure whether anyone has tried this
> 
> InputStream is always blocking.
> 
> Are you trying to use async? That's not the way to use async...
> 
> -chris
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Re: Tomcat 9.0 async read becomes blocking

[Christopher Schultz]

Andrew,

On 9/21/21 13:54, Javateck wrote:

Hi,

With NIO connector with Servlet 3.1 support, I’m registering with a 
ReadListener, while it got the first read signal from tomcat container (I tried 
9.0.19 and 9.0.53), the read call is blocked after isReady returns true

   if (ServletInputStream.isReady()) {
ServletInputStream.read(buffer);  // this becomes blocking
   }

I tried with jetty, it’s working fine

When I did the test, I was holding the sending packet from client side

Not sure whether anyone has tried this


InputStream is always blocking.

Are you trying to use async? That's not the way to use async...

-chris

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

Re: Tomcat 9.0 async read becomes blocking

[Javateck]

It’s happening in chunk encoding

> On Sep 21, 2021, at 10:54 AM, Javateck  wrote:
> 
> Hi,
> 
> With NIO connector with Servlet 3.1 support, I’m registering with a 
> ReadListener, while it got the first read signal from tomcat container (I 
> tried 9.0.19 and 9.0.53), the read call is blocked after isReady returns true
> 
>  if (ServletInputStream.isReady()) {
>   ServletInputStream.read(buffer);  // this becomes blocking
>  }
> 
> I tried with jetty, it’s working fine
> 
> When I did the test, I was holding the sending packet from client side
> 
> Not sure whether anyone has tried this
> 
> Thanks,
> Andrew
> 

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

Tomcat 9.0 async read becomes blocking

[Javateck]

Hi,

With NIO connector with Servlet 3.1 support, I’m registering with a 
ReadListener, while it got the first read signal from tomcat container (I tried 
9.0.19 and 9.0.53), the read call is blocked after isReady returns true

  if (ServletInputStream.isReady()) {
   ServletInputStream.read(buffer);  // this becomes blocking
  }

I tried with jetty, it’s working fine

When I did the test, I was holding the sending packet from client side

Not sure whether anyone has tried this

Thanks,
Andrew


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

Re: OpenSSL issues with Tomcat 9.0 on Corretto

[Pawel Veselov]

Hello.

On Fri, Jul 2, 2021 at 1:04 AM Pawel Veselov  wrote:
>
> Hello.
>
> We've been using Tomcat 9 OpenJDK(8) images for a while, but are now
> trying to switch to Corretto.

I sincerely apologize. I didn't realize that Tomcat images weren't maintained
by the Tomcat group. I probably need to take this here:
https://github.com/docker-library/tomcat

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

OpenSSL issues with Tomcat 9.0 on Corretto

[Pawel Veselov]

Hello.

We've been using Tomcat 9 OpenJDK(8) images for a while, but are now
trying to switch to Corretto.

The problem we ran into is that tomcat-native is built with OpenSSL
1.0 libraries.
That makes it impossible to use Ed25519 certificates.
I don't think it's possible to rectify that at runtime.

Are there any plans to switch to using OpenSSL 1.1 instead? Especially
considering that the OpenJDK variant is built with 1.1?

Thank you!

-- 
With best of best regards
Pawel S. Veselov

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

Re: Tomcat 9.0

[Martin Grigorov]

Hi,

On Thu, Apr 8, 2021 at 3:25 AM Mohamed Eliyas Abdul Kadar <
mohamed.ka...@neogenomics.com> wrote:

> Hi All
> I am planning to use Tomcat for my development server. Initially we
> planned to go with version Tomcat 9.0.41. Now I see newer versions are
> release on top of that and see the latest version is Tomcat 9.0.45. Please
> let me know if there is any major fix of Tomcat 9.0.41 made on higher
> versions or we are good with Tomcat 9.0.44 as Tomcat 9.0.45 is not having
> any release date.
>

Please consult with https://tomcat.apache.org/tomcat-9.0-doc/changelog.html
for the changes in each version.

Martin


>
> Regards
> Eliyas
> This communication and its attachments contain confidential information
> and is intended only for the named addressee. If you are not the named
> addressee you should not disseminate, distribute or copy this
> communication. Please notify the sender immediately if you have received
> this communication by mistake and delete or destroy this communication.
> Communications cannot be guaranteed to be secured or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive late
> or incomplete, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this communication
> which arise as a result of transmission. If verification is required please
> request a hard-copy version. NeoGenomics Laboratories, 12701 Commonwealth
> Dr, Fort Myers, FL 33913, http://www.neogenomics.com (2021)
>

RE: Tomcat 9.0

[jonmcalexander]

Tomcat 9.0.45 was released on 4/6/2021.

Dream * Excel * Explore * Inspire
Jon McAlexander
Infrastructure Engineer
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

Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
12/30/2020, 12/31/2020
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: Mohamed Eliyas Abdul Kadar 
> Sent: Wednesday, April 7, 2021 7:24 PM
> To: users@tomcat.apache.org
> Subject: Tomcat 9.0
> 
> Hi All
> I am planning to use Tomcat for my development server. Initially we planned
> to go with version Tomcat 9.0.41. Now I see newer versions are release on
> top of that and see the latest version is Tomcat 9.0.45. Please let me know if
> there is any major fix of Tomcat 9.0.41 made on higher versions or we are
> good with Tomcat 9.0.44 as Tomcat 9.0.45 is not having any release date.
> 
> Regards
> Eliyas
> This communication and its attachments contain confidential information and
> is intended only for the named addressee. If you are not the named
> addressee you should not disseminate, distribute or copy this
> communication. Please notify the sender immediately if you have received
> this communication by mistake and delete or destroy this communication.
> Communications cannot be guaranteed to be secured or error-free as
> information could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. The sender therefore does not accept liability
> for any errors or omissions in the contents of this communication which arise
> as a result of transmission. If verification is required please request a 
> hard-
> copy version. NeoGenomics Laboratories, 12701 Commonwealth Dr, Fort
> Myers, FL 33913,
> https://urldefense.com/v3/__http://www.neogenomics.com__;!!F9svGWnI
> aVPGSwU!-AkpZzxZPuQUL60dCm7hELiY0GltGFPS-
> uLpndY22TTi2oX1GQy3NNmqZqniOmqShaV3wFQ$  (2021)

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

Tomcat 9.0

[Mohamed Eliyas Abdul Kadar]

Hi All
I am planning to use Tomcat for my development server. Initially we planned to 
go with version Tomcat 9.0.41. Now I see newer versions are release on top of 
that and see the latest version is Tomcat 9.0.45. Please let me know if there 
is any major fix of Tomcat 9.0.41 made on higher versions or we are good with 
Tomcat 9.0.44 as Tomcat 9.0.45 is not having any release date.

Regards
Eliyas
This communication and its attachments contain confidential information and is 
intended only for the named addressee. If you are not the named addressee you 
should not disseminate, distribute or copy this communication. Please notify 
the sender immediately if you have received this communication by mistake and 
delete or destroy this communication. Communications cannot be guaranteed to be 
secured or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. The sender therefore 
does not accept liability for any errors or omissions in the contents of this 
communication which arise as a result of transmission. If verification is 
required please request a hard-copy version. NeoGenomics Laboratories, 12701 
Commonwealth Dr, Fort Myers, FL 33913, http://www.neogenomics.com (2021)

tomcat 9.0 cache warning errors

[Jim Anderson]

While writing this post, I managed to fix my own problem with help from 
the internet. The solution is for anyone running tomcat v 9.0 inside 
eclipse.


Tomcat v9.0 in eclipse gave me a large number of cache warning errors 
and eventually crashed.  While verifying the problem, I discovered a fix 
discussed at the following url:


https://stackoverflow.com/questions/14771710/how-to-solve-javax-servlet-servletexception-java-lang-unsupportedclassversioner

That site recommended adding the following line to the tomcat path 
.../config/context.xml.


| I added that 
line to context.xml and after several iterations of trying, the |||cacheMaxSize value was 60 (i.e. 600M-bytes in size). The website I 
am working on only contains 22 M-bytes so cache size should not have 
been an issue, but the warnings kept coming. Then I thought, maybe 
Eclipse has its own version of tomcat 9.0 and sure enough I found there 
is a tomcat v 9.0 sub-directory in eclipse/workspace/Servers directory. 
I added the 'Resources' line shown above to the the conf/context.xml 
file in the eclipse tomcat v 9.0 sub-directory and that fixed my 
problem. |So the 2 step fix for cache error messages is: 1) locate the 
correct version of tomcat in your eclipse workspace 2) add "|||" to your 
context.xml file. I will update the stackoverflow.com URL with a 
comment. I'm not sure if this is worth mentioning anywhere in the tomcat 
documentation. I will leave that to others.||


--
Jim Anderson

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Madhan,

On 6/12/20 00:57, Madhan Raj wrote:
> Just attached the outputs logs and my server.xml including my
> ecdsa cert. in keystoreand s_client outputs.txt file i have
> attached all the required cert and keystore outputs.

In-line would be better in the future. I hate having to save
attachments on my own computer and then edit them just to see them.
And then copy/paste to quote.

> [root@sapphire-69 conf]# keytool -list -v -keystore
> /usr/local/platform/.security/tomcat-ECDSA/certs/tomcat-ECDSA.keystore
> -storepass iY4VjgcxNrTLp57b  -storetype PKCS12log4j:WARN No
> appenders could be found for logger
> (com.cisco.ciscossl.provider.ciscojce.CiscoJEnv). log4j:WARN Please
> initialize the log4j system properly. log4j:WARN See
> http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
> info. Keystore type: PKCS12 Keystore provider: JsafeJCE

Could this be of interest (repeating above):
> Keystore provider: JsafeJCE

I didn't see certificateKeystoreProvider="JsafeJCE" in your
 configuration.

Does your RSA keystore show the same keystore provider if you dump it?

> [snip] [from keytool] Owner: L=blr, ST=kr, CN=sapphire-69-EC,
> OU=cisco, O=infy, C=IN [snip] Signature algorithm name:
> SHA384withECDSA Subject Public Key Algorithm: 384-bit EC key>
> [snip] [from openssl] X509v3 Subject Alternative Name:
> DNS:sapphire-69

Your CN is "sapphire-69-EC" and you have a SAN for "sapphire-69". Is
that also the hostname being used to connect?

> What client are you using to attempt the handshake? i am using
> openssl command line utility to test

Good.

> What error(s) do you get with the handshake?  secure negotiation
> not supported

That's not an error. It's one of many messages from openssl s_client:

> # openssl s_client -connect localhost:443 CONNECTED(0003)
> 139656609052336:error:140790E5:SSL routines:ssl23_write:ssl
> handshake failure:s23_lib.c:177: --- no peer certificate available
> --- No client certificate CA names sent --- SSL handshake has read
> 0 bytes and written 247 bytes --- New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported Compression: NONE Expansion:
> NONE No ALPN negotiated SSL-Session: Protocol  : TLSv1.2 Cipher
> :  Session-ID: Session-ID-ctx: Master-Key: Key-Arg   : None PSK
> identity: None PSK identity hint: None SRP username: None Start
> Time: 1591935501 Timeout   : 300 (sec) Verify return code: 0 (ok)
> ---

You are using "localhost". What if you use "sapphire-69"?

...although localhost:8443 seems to work with your RSA certificate.

> If you configure *only* ESDSA, can you handshake? Or does ECDSA
> never work?   correct ECDSA never work for me. here in my case on
> port 443 i hosted only ECDSA keystore and on 8443 i have hosted RSA
> keystore. 8443 works like charm and 443 is down

> [From your config:]  ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>
>
protocols="TLSv1,TLSv1.1,TLSv1.2" sessionCacheSize="1"
> sessionTimeout="1800" sslProtocol="TLS" truststoreType="PKCS12">
Note that you can't handshake using an RSA authentication with an
ECDSA certificate. While those ECDHE-RSA-* ciphers in there won't
hurt, they will never work and are a little confusing.

What happens if you point this tool at your localhost:443 and
localhost:8443 endpoints?

https://github.com/ChristopherSchultz/ssltest

- -chris

> On Thu, Jun 11, 2020 at 1:47 PM Christopher Schultz
>  >
wrote:
>
> Madhan,
>
> On 6/10/20 22:08, Madhan Raj wrote:
>> Any insights please .
>
> How did you create your certificate?
>
> What are the details of your certificate and key? For example,
> which curve are you using? How many key bits? What type of
> signature on the certificate? What is the alias for that
> certificate in your keystore? Does it match what you have
> configured in Tomcat? Do you have a password on your keystore? Are
> you setting that correctly in your  element? (I see no
> password in your posted config.)
>
> What client are you using to attempt the handshake?
>
> What error(s) do you get with the handshake?
>
> If you configure *only* ESDSA, can you handshake? Or does ECDSA
> never work?
>
> You haven't give us much to go on, other than "I can't get ESDSA
> to work" when it's pretty clear others can get it to work.
>
> -chris
>
>> On Thu, 4 Jun, 2020, 11:12 pm Madhan Raj,  
>> >>
>> wrote:
>
>> Hi Christopher,
>
>> Yes you correct I can only complete a handshake with RSA cert,
>> not ECDSA cert. when i try to connect with ECDSA ciphers using
>> s_client negotiation fails. Madhan
>
>> On Thu, Jun 4, 2020 at 12:41 PM Christopher Schultz
>> > 
>>  

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Madhan Raj]

Hi Chris,

Just attached the outputs logs and my server.xml including my ecdsa cert.
in keystoreand s_client outputs.txt file i have attached all the required
cert and keystore outputs.

What client are you using to attempt the handshake? i am using openssl
command line utility to test

What error(s) do you get with the handshake?  secure negotiation not
supported

If you configure *only* ESDSA, can you handshake? Or does ECDSA never
work?   correct ECDSA never work for me.
here in my case on port 443 i hosted only ECDSA keystore and on 8443 i have
hosted RSA keystore.
8443 works like charm and 443 is down

Thanks,
Madhan.

On Thu, Jun 11, 2020 at 1:47 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Madhan,
>
> On 6/10/20 22:08, Madhan Raj wrote:
> > Any insights please .
>
> How did you create your certificate?
>
> What are the details of your certificate and key? For example, which
> curve are you using? How many key bits? What type of signature on the
> certificate? What is the alias for that certificate in your keystore?
> Does it match what you have configured in Tomcat? Do you have a
> password on your keystore? Are you setting that correctly in your
>  element? (I see no password in your posted config.)
>
> What client are you using to attempt the handshake?
>
> What error(s) do you get with the handshake?
>
> If you configure *only* ESDSA, can you handshake? Or does ECDSA never
> work?
>
> You haven't give us much to go on, other than "I can't get ESDSA to
> work" when it's pretty clear others can get it to work.
>
> - -chris
>
> > On Thu, 4 Jun, 2020, 11:12 pm Madhan Raj,  > > wrote:
> >
> > Hi Christopher,
> >
> > Yes you correct I can only complete a handshake with RSA cert, not
> > ECDSA cert. when i try to connect with ECDSA ciphers using
> > s_client negotiation fails. Madhan
> >
> > On Thu, Jun 4, 2020 at 12:41 PM Christopher Schultz
> >  > > wrote:
> >
> > Madhan,
> >
> > On 6/3/20 21:08, Madhan Raj wrote:
> >> OS - CentOS 7.6.1810( Core)
> >
> >> Below connector doesn't load my EC keystore whereas it works
> >> with RSA . Any insights please .
> >
> > When you say "doesn't load", what do you mean? Possible reasonable
> > responses are:
> >
> > 1. I can only complete a handshake with RSA cert, not ECDSA cert 2.
> > Error message (please post) 3. JVM crashes 4. OS crashes 5.
> > Universe ends (possible, but unlikely to be reproducible)
> >
> >> this is my connector tag  in server.xml  >> SSLEnabled="true" URIEncoding="UTF-8"  maxThreads="200"
> >> port="443" scheme="https" secure="true"
> >> protocol="org.apache.coyote.http11.Http11NioProtocol"
> >
> > sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
> >
> >
> ion"
> >
> >
> > disableUploadTimeout="true" enableLookups="false"
> > maxHttpHeaderSize="819 2"
> >> minSpareThreads="25">  >> certificateVerification="none" sessionTimeout="1800"
> >> protocols="TLSv1,TLSv1.1,TLSv1.2,TLSv1.3"
> >
> > ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
> >
> >
> HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
> > S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
> >
> >
> > sessionCacheSize="1">
> >>  >
> > certificateKeystoreFile="/usr/local/platform/.security/tomcat-ECDSA/ce
> >
> >
> rts/tomcat-ECDSA.keystore"
> >
> >
> > certificateKeystorePassword="8o8yeAH2qSJbJ2sn"
> >> certificateKeystoreType="PKCS12" type="EC"/> 
> >> 
> >
> >> tomcat start up command used :- /home/tomcat/tomcat -user tomcat
> >> -home /usr/local/thirdparty/java/j2sdk -pidfile
> >> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
> >> /home/tomcat/tomcat -outfile
> >> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile
> >> &1 -Djdk.tls.ephemeralDHKeySize=2048
> >> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> >> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
> >
> > -Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/c
> >
> >
> onf/logging.properties
> >
> >
> > -
> > -agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,sus
> pe
> >
> >
> nd=n
> >> -XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80
> >> -Xmx1824m -Xms256m
> >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> >>
> >>
> - -cp
> >
> > /usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thir
> >
> >
> dparty/jakarta-tomcat/bin/tomcat-juli.jar
> >
> >
> > -
> > -Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/cata
> li
> >
> >
> na.policy
> >> -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
> >> -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
> >> -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
> >> org.apache.catalina.startup.Bootstrap start'
> >
> >> JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
> >> -Djavax.net.ssl.sessionCacheSize=1
> >
> 

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Madhan,

On 6/10/20 22:08, Madhan Raj wrote:
> Any insights please .

How did you create your certificate?

What are the details of your certificate and key? For example, which
curve are you using? How many key bits? What type of signature on the
certificate? What is the alias for that certificate in your keystore?
Does it match what you have configured in Tomcat? Do you have a
password on your keystore? Are you setting that correctly in your
 element? (I see no password in your posted config.)

What client are you using to attempt the handshake?

What error(s) do you get with the handshake?

If you configure *only* ESDSA, can you handshake? Or does ECDSA never
work?

You haven't give us much to go on, other than "I can't get ESDSA to
work" when it's pretty clear others can get it to work.

- -chris

> On Thu, 4 Jun, 2020, 11:12 pm Madhan Raj,  > wrote:
>
> Hi Christopher,
>
> Yes you correct I can only complete a handshake with RSA cert, not
> ECDSA cert. when i try to connect with ECDSA ciphers using
> s_client negotiation fails. Madhan
>
> On Thu, Jun 4, 2020 at 12:41 PM Christopher Schultz
>  > wrote:
>
> Madhan,
>
> On 6/3/20 21:08, Madhan Raj wrote:
>> OS - CentOS 7.6.1810( Core)
>
>> Below connector doesn't load my EC keystore whereas it works
>> with RSA . Any insights please .
>
> When you say "doesn't load", what do you mean? Possible reasonable
> responses are:
>
> 1. I can only complete a handshake with RSA cert, not ECDSA cert 2.
> Error message (please post) 3. JVM crashes 4. OS crashes 5.
> Universe ends (possible, but unlikely to be reproducible)
>
>> this is my connector tag  in server.xml > SSLEnabled="true" URIEncoding="UTF-8"  maxThreads="200"
>> port="443" scheme="https" secure="true"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
>
>
ion"
>
>
> disableUploadTimeout="true" enableLookups="false"
> maxHttpHeaderSize="819 2"
>> minSpareThreads="25"> > certificateVerification="none" sessionTimeout="1800"
>> protocols="TLSv1,TLSv1.1,TLSv1.2,TLSv1.3"
>
> ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
>
>
HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
> S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>
>
> sessionCacheSize="1">
>> 
> certificateKeystoreFile="/usr/local/platform/.security/tomcat-ECDSA/ce
>
>
rts/tomcat-ECDSA.keystore"
>
>
> certificateKeystorePassword="8o8yeAH2qSJbJ2sn"
>> certificateKeystoreType="PKCS12" type="EC"/> 
>> 
>
>> tomcat start up command used :- /home/tomcat/tomcat -user tomcat
>> -home /usr/local/thirdparty/java/j2sdk -pidfile
>> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
>> /home/tomcat/tomcat -outfile
>> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile
>> &1 -Djdk.tls.ephemeralDHKeySize=2048
>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
>
> -Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/c
>
>
onf/logging.properties
>
>
> -
> -agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,sus
pe
>
>
nd=n
>> -XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80
>> -Xmx1824m -Xms256m
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>
>>
- -cp
>
> /usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thir
>
>
dparty/jakarta-tomcat/bin/tomcat-juli.jar
>
>
> -
> -Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/cata
li
>
>
na.policy
>> -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
>> -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
>> -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
>> org.apache.catalina.startup.Bootstrap start'
>
>> JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
>> -Djavax.net.ssl.sessionCacheSize=1
>
> -Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-
>
>
certs/tomcat-trust.keystore
>
>
> -Djavax.net.ssl.trustStorePassword=$TRUST_STORE_PASSWORD
>
> -XX:ErrorFile=$CATALINA_HOME/logs/diagnostic-info.jvm-crash.%p.tomcat.
>
>
txt
>
>
> -Dsun.zip.disableMemoryMapping=true
>> -XX:OnOutOfMemoryError=/home/tomcat/tomcat_diagnostics.sh
>> -XX:OnError=/home/tomcat/tomcat_diagnostics.sh $TOMCAT_JAVA_OPTS
>
>> Also can i have both RSA and ECDSA in a single keystore. Will
>> that work in tomcat 9?
>
> Yes. You have to use two  elements each with a
> different "type" and "certificateKeyAlias"
>
>> it used to work with tomat 7
>
> It still works with Tomcat 9.
>
> -chris
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ibjkACgkQHPApP6U8
pFheVg//akO4QY2HP7S7zfseHqH3lb1ZsU4JxjGkCXNCGhX1lju3tAaGEqAEb/VG
ecnGaf/lvdhKlcNfI26ZdRjb0QM6CWwrhIvrnkRe8Yf5kYHFMRkIkllMMF27hhGd
aJV2urneiP8S2vHV

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Madhan Raj]

Hi all,

Any insights please .

Thanks,
Madhan

On Thu, 4 Jun, 2020, 11:12 pm Madhan Raj,  wrote:

> Hi Christopher,
>
> Yes you correct I can only complete a handshake with RSA cert, not ECDSA
> cert. when i try to connect with ECDSA ciphers using s_client negotiation
> fails.
> Madhan
>
> On Thu, Jun 4, 2020 at 12:41 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Madhan,
>>
>> On 6/3/20 21:08, Madhan Raj wrote:
>> > OS - CentOS 7.6.1810( Core)
>> >
>> > Below connector doesn't load my EC keystore whereas it works with
>> > RSA . Any insights please .
>>
>> When you say "doesn't load", what do you mean? Possible reasonable
>> responses are:
>>
>> 1. I can only complete a handshake with RSA cert, not ECDSA cert
>> 2. Error message (please post)
>> 3. JVM crashes
>> 4. OS crashes
>> 5. Universe ends (possible, but unlikely to be reproducible)
>>
>> > this is my connector tag  in server.xml > > SSLEnabled="true" URIEncoding="UTF-8"  maxThreads="200" port="443"
>> > scheme="https" secure="true"
>> > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> > sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
>> ion"
>> >
>> >
>> disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="819
>> 2"
>> > minSpareThreads="25"> > > certificateVerification="none" sessionTimeout="1800"
>> > protocols="TLSv1,TLSv1.1,TLSv1.2,TLSv1.3"
>> > ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
>> HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
>> S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>> >
>> >
>> sessionCacheSize="1">
>> > > > certificateKeystoreFile="/usr/local/platform/.security/tomcat-ECDSA/ce
>> rts/tomcat-ECDSA.keystore"
>> >
>> >
>> certificateKeystorePassword="8o8yeAH2qSJbJ2sn"
>> > certificateKeystoreType="PKCS12" type="EC"/> 
>> > 
>> >
>> > tomcat start up command used :- /home/tomcat/tomcat -user tomcat
>> > -home /usr/local/thirdparty/java/j2sdk -pidfile
>> > /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
>> > /home/tomcat/tomcat -outfile
>> > /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
>> > -Djdk.tls.ephemeralDHKeySize=2048
>> > -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
>> > -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
>> > -Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/c
>> onf/logging.properties
>> >
>> >
>> - -agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,suspe
>> nd=n
>> > -XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80
>> > -Xmx1824m -Xms256m
>> > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> > -cp
>> > /usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thir
>> dparty/jakarta-tomcat/bin/tomcat-juli.jar
>> >
>> >
>> - -Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catali
>> na.policy
>> > -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
>> > -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
>> > -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
>> > org.apache.catalina.startup.Bootstrap start'
>> >
>> > JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
>> > -Djavax.net.ssl.sessionCacheSize=1
>> > -Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-
>> certs/tomcat-trust.keystore
>> >
>> >
>> - -Djavax.net.ssl.trustStorePassword=$TRUST_STORE_PASSWORD
>> > -XX:ErrorFile=$CATALINA_HOME/logs/diagnostic-info.jvm-crash.%p.tomcat.
>> txt
>> >
>> >
>> - -Dsun.zip.disableMemoryMapping=true
>> > -XX:OnOutOfMemoryError=/home/tomcat/tomcat_diagnostics.sh
>> > -XX:OnError=/home/tomcat/tomcat_diagnostics.sh $TOMCAT_JAVA_OPTS
>> >
>> > Also can i have both RSA and ECDSA in a single keystore. Will that
>> > work in tomcat 9?
>>
>> Yes. You have to use two  elements each with a different
>> "type" and "certificateKeyAlias"
>>
>> > it used to work with tomat 7
>>
>> It still works with Tomcat 9.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>>
>> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ZJEwACgkQHPApP6U8
>> pFg/Tg/9El60qkdMWwk6SpBiKjy0rgQEYgmdv2hkVQXmfX4uaWHZuEBDydX/xQ9L
>> 3JaS+rDeM/4Z6Y7HrKqLGQ0Q+mtgWSoXohhGAqZMcsaGtdiz9oBYukRW7e0JG4Hv
>> OZgmyPUifLH0kPDyrql3feLQL9TW7G998rR9+N2BsFWnyVdaHYIWt2vSu+/vak7T
>> OqqNj0Wze9G8/OudKXCEQBi1ADql8XAt7hRCaQLHRcaDLEVLnULq6lgol0dV9qXM
>> suzNGud9VWNUgsoNX7wZDmx2xYnvDUfOnUJSEYLfRV6zFHOJOLiKLk8GBjymLVt3
>> PEW3EXlJpq2rQo++s4tNhJGjZRR7yEGNRUO1bl/eB7O4MZrwpZyV9lmy2TN2Im5g
>> LsMas3p3m87vz8ajafo9SDSZkmXmJ270dUZd8MAxxIvDSCnhw0trSTxbppgeb7p4
>> LGn/gA9igAY9S9PUKkyLocKVW9XpRg1v21WCSyifKzM7b0787e1EFx6rhxBTsZAk
>> 7D7nL+0Em61LRQKaM3noDtyofEzYGoUtaRwv5gx+dCfF5huDCKvkhWxGQfAwiE/3
>> fRHCZK1la1Jn3wikApLXU6iEjXV33TmF/hAjLOPaizl90AYxR6O4pvwRKOF+9+fV
>> Z4CO1ysmLK/WHTYXcpZ8/zPEo9EgXbTULU9DiDu3N6+LKrUFQcc=
>> =L+y6
>> -END PGP SIGNATURE-
>>
>

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[logo]

Madhan,


> Am 04.06.2020 um 18:41 schrieb Christopher Schultz 
> :
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Madhan,
> 
> On 6/3/20 21:08, Madhan Raj wrote:
>> OS - CentOS 7.6.1810( Core)
>> 
>> Below connector doesn't load my EC keystore whereas it works with
>> RSA . Any insights please .

Try to update to the latest version. Check the change log. In 9.0.31 support 
for EC keys was at least updated. Maybe this will work. I had problems using 
unencrypted EC keys in Tomcat 8.5.50 in JSSE connectors - however with pem 
encoded cert files (fixed in 8.5.51). But yours may be a similar problem.

Regards

Peter

> 
> When you say "doesn't load", what do you mean? Possible reasonable
> responses are:
> 
> 1. I can only complete a handshake with RSA cert, not ECDSA cert
> 2. Error message (please post)
> 3. JVM crashes
> 4. OS crashes
> 5. Universe ends (possible, but unlikely to be reproducible)
> 
>> this is my connector tag  in server.xml > SSLEnabled="true" URIEncoding="UTF-8"  maxThreads="200" port="443"
>> scheme="https" secure="true"
>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
> ion"
>> 
>> 
> disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="819
> 2"
>> minSpareThreads="25"> > certificateVerification="none" sessionTimeout="1800"
>> protocols="TLSv1,TLSv1.1,TLSv1.2,TLSv1.3"
>> ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
> HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
> S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>> 
>> 
> sessionCacheSize="1">
>> > certificateKeystoreFile="/usr/local/platform/.security/tomcat-ECDSA/ce
> rts/tomcat-ECDSA.keystore"
>> 
>> 
> certificateKeystorePassword="8o8yeAH2qSJbJ2sn"
>> certificateKeystoreType="PKCS12" type="EC"/> 
>> 
>> 
>> tomcat start up command used :- /home/tomcat/tomcat -user tomcat
>> -home /usr/local/thirdparty/java/j2sdk -pidfile
>> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
>> /home/tomcat/tomcat -outfile
>> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
>> -Djdk.tls.ephemeralDHKeySize=2048
>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
>> -Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/c
> onf/logging.properties
>> 
>> 
> - -agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,suspe
> nd=n
>> -XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80
>> -Xmx1824m -Xms256m
>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>> -cp
>> /usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thir
> dparty/jakarta-tomcat/bin/tomcat-juli.jar
>> 
>> 
> - -Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catali
> na.policy
>> -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
>> -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
>> -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
>> org.apache.catalina.startup.Bootstrap start'
>> 
>> JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
>> -Djavax.net.ssl.sessionCacheSize=1
>> -Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-
> certs/tomcat-trust.keystore
>> 
>> 
> - -Djavax.net.ssl.trustStorePassword=$TRUST_STORE_PASSWORD
>> -XX:ErrorFile=$CATALINA_HOME/logs/diagnostic-info.jvm-crash.%p.tomcat.
> txt
>> 
>> 
> - -Dsun.zip.disableMemoryMapping=true
>> -XX:OnOutOfMemoryError=/home/tomcat/tomcat_diagnostics.sh
>> -XX:OnError=/home/tomcat/tomcat_diagnostics.sh $TOMCAT_JAVA_OPTS
>> 
>> Also can i have both RSA and ECDSA in a single keystore. Will that
>> work in tomcat 9?
> 
> Yes. You have to use two  elements each with a different
> "type" and "certificateKeyAlias"
> 
>> it used to work with tomat 7
> 
> It still works with Tomcat 9.
> 
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ZJEwACgkQHPApP6U8
> pFg/Tg/9El60qkdMWwk6SpBiKjy0rgQEYgmdv2hkVQXmfX4uaWHZuEBDydX/xQ9L
> 3JaS+rDeM/4Z6Y7HrKqLGQ0Q+mtgWSoXohhGAqZMcsaGtdiz9oBYukRW7e0JG4Hv
> OZgmyPUifLH0kPDyrql3feLQL9TW7G998rR9+N2BsFWnyVdaHYIWt2vSu+/vak7T
> OqqNj0Wze9G8/OudKXCEQBi1ADql8XAt7hRCaQLHRcaDLEVLnULq6lgol0dV9qXM
> suzNGud9VWNUgsoNX7wZDmx2xYnvDUfOnUJSEYLfRV6zFHOJOLiKLk8GBjymLVt3
> PEW3EXlJpq2rQo++s4tNhJGjZRR7yEGNRUO1bl/eB7O4MZrwpZyV9lmy2TN2Im5g
> LsMas3p3m87vz8ajafo9SDSZkmXmJ270dUZd8MAxxIvDSCnhw0trSTxbppgeb7p4
> LGn/gA9igAY9S9PUKkyLocKVW9XpRg1v21WCSyifKzM7b0787e1EFx6rhxBTsZAk
> 7D7nL+0Em61LRQKaM3noDtyofEzYGoUtaRwv5gx+dCfF5huDCKvkhWxGQfAwiE/3
> fRHCZK1la1Jn3wikApLXU6iEjXV33TmF/hAjLOPaizl90AYxR6O4pvwRKOF+9+fV
> Z4CO1ysmLK/WHTYXcpZ8/zPEo9EgXbTULU9DiDu3N6+LKrUFQcc=
> =L+y6
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additio

Re: tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Madhan,

On 6/3/20 21:08, Madhan Raj wrote:
> OS - CentOS 7.6.1810( Core)
>
> Below connector doesn't load my EC keystore whereas it works with
> RSA . Any insights please .

When you say "doesn't load", what do you mean? Possible reasonable
responses are:

1. I can only complete a handshake with RSA cert, not ECDSA cert
2. Error message (please post)
3. JVM crashes
4. OS crashes
5. Universe ends (possible, but unlikely to be reproducible)

> this is my connector tag  in server.xml  SSLEnabled="true" URIEncoding="UTF-8"  maxThreads="200" port="443"
> scheme="https" secure="true"
> protocol="org.apache.coyote.http11.Http11NioProtocol"
> sslImplementationName="org.apache.tomcat.util.net.jsse.JSSEImplementat
ion"
>
>
disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="819
2"
> minSpareThreads="25">  certificateVerification="none" sessionTimeout="1800"
> protocols="TLSv1,TLSv1.1,TLSv1.2,TLSv1.3"
> ciphers="ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECD
HE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:AES256-SHA:DHE-DS
S-AES256-SHA:AES128-SHA:DHE-RSA-AES128-SHA"
>
>
sessionCacheSize="1">
>  certificateKeystoreFile="/usr/local/platform/.security/tomcat-ECDSA/ce
rts/tomcat-ECDSA.keystore"
>
>
certificateKeystorePassword="8o8yeAH2qSJbJ2sn"
> certificateKeystoreType="PKCS12" type="EC"/> 
> 
>
> tomcat start up command used :- /home/tomcat/tomcat -user tomcat
> -home /usr/local/thirdparty/java/j2sdk -pidfile
> /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
> /home/tomcat/tomcat -outfile
> /usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
> -Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/c
onf/logging.properties
>
>
- -agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,suspe
nd=n
> -XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80
> -Xmx1824m -Xms256m
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -cp
> /usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thir
dparty/jakarta-tomcat/bin/tomcat-juli.jar
>
>
- -Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catali
na.policy
> -Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
> -Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
> -Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
> org.apache.catalina.startup.Bootstrap start'
>
> JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
> -Djavax.net.ssl.sessionCacheSize=1
> -Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-
certs/tomcat-trust.keystore
>
>
- -Djavax.net.ssl.trustStorePassword=$TRUST_STORE_PASSWORD
> -XX:ErrorFile=$CATALINA_HOME/logs/diagnostic-info.jvm-crash.%p.tomcat.
txt
>
>
- -Dsun.zip.disableMemoryMapping=true
> -XX:OnOutOfMemoryError=/home/tomcat/tomcat_diagnostics.sh
> -XX:OnError=/home/tomcat/tomcat_diagnostics.sh $TOMCAT_JAVA_OPTS
>
> Also can i have both RSA and ECDSA in a single keystore. Will that
> work in tomcat 9?

Yes. You have to use two  elements each with a different
"type" and "certificateKeyAlias"

> it used to work with tomat 7

It still works with Tomcat 9.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7ZJEwACgkQHPApP6U8
pFg/Tg/9El60qkdMWwk6SpBiKjy0rgQEYgmdv2hkVQXmfX4uaWHZuEBDydX/xQ9L
3JaS+rDeM/4Z6Y7HrKqLGQ0Q+mtgWSoXohhGAqZMcsaGtdiz9oBYukRW7e0JG4Hv
OZgmyPUifLH0kPDyrql3feLQL9TW7G998rR9+N2BsFWnyVdaHYIWt2vSu+/vak7T
OqqNj0Wze9G8/OudKXCEQBi1ADql8XAt7hRCaQLHRcaDLEVLnULq6lgol0dV9qXM
suzNGud9VWNUgsoNX7wZDmx2xYnvDUfOnUJSEYLfRV6zFHOJOLiKLk8GBjymLVt3
PEW3EXlJpq2rQo++s4tNhJGjZRR7yEGNRUO1bl/eB7O4MZrwpZyV9lmy2TN2Im5g
LsMas3p3m87vz8ajafo9SDSZkmXmJ270dUZd8MAxxIvDSCnhw0trSTxbppgeb7p4
LGn/gA9igAY9S9PUKkyLocKVW9XpRg1v21WCSyifKzM7b0787e1EFx6rhxBTsZAk
7D7nL+0Em61LRQKaM3noDtyofEzYGoUtaRwv5gx+dCfF5huDCKvkhWxGQfAwiE/3
fRHCZK1la1Jn3wikApLXU6iEjXV33TmF/hAjLOPaizl90AYxR6O4pvwRKOF+9+fV
Z4CO1ysmLK/WHTYXcpZ8/zPEo9EgXbTULU9DiDu3N6+LKrUFQcc=
=L+y6
-END PGP SIGNATURE-

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

tomcat 9.0 doesn't load the ECDSA keystore. (ver # 9.0.24)

[Madhan Raj]

Hi All,

OS - CentOS 7.6.1810( Core)

Below connector doesn't load my EC keystore whereas it works with RSA . Any
insights please .

this is my connector tag  in server.xml






tomcat start up command used :-
 /home/tomcat/tomcat -user tomcat -home /usr/local/thirdparty/java/j2sdk
-pidfile /usr/local/thirdparty/jakarta-tomcat/conf/tomcat.pid -procname
/home/tomcat/tomcat -outfile
/usr/local/thirdparty/jakarta-tomcat/logs/catalina.out -errfile &1
-Djdk.tls.ephemeralDHKeySize=2048
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027
-Djava.util.logging.config.file=/usr/local/thirdparty/jakarta-tomcat/conf/logging.properties
-agentlib:jdwp=transport=dt_socket,address=localhost:8000,server=y,suspend=n
-XX:+UseParallelGC -XX:GCTimeRatio=99 -XX:MaxGCPauseMillis=80 -Xmx1824m
-Xms256m -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-cp
/usr/local/thirdparty/jakarta-tomcat/bin/bootstrap.jar:/usr/local/thirdparty/jakarta-tomcat/bin/tomcat-juli.jar
-Djava.security.policy==/usr/local/thirdparty/jakarta-tomcat/conf/catalina.policy
-Dcatalina.base=/usr/local/thirdparty/jakarta-tomcat
-Dcatalina.home=/usr/local/thirdparty/jakarta-tomcat
-Djava.io.tmpdir=/usr/local/thirdparty/jakarta-tomcat/temp
org.apache.catalina.startup.Bootstrap start'

JAVA_OPTS= -Djava.library.path=$LD_LIBRARY_PATH
-Djavax.net.ssl.sessionCacheSize=1
 
-Djavax.net.ssl.trustStore=/usr/local/platform/.security/tomcat/trust-certs/tomcat-trust.keystore
-Djavax.net.ssl.trustStorePassword=$TRUST_STORE_PASSWORD
-XX:ErrorFile=$CATALINA_HOME/logs/diagnostic-info.jvm-crash.%p.tomcat.txt
-Dsun.zip.disableMemoryMapping=true
-XX:OnOutOfMemoryError=/home/tomcat/tomcat_diagnostics.sh
-XX:OnError=/home/tomcat/tomcat_diagnostics.sh $TOMCAT_JAVA_OPTS

Also can i have both RSA and ECDSA in a single keystore .Will that work in
tomcat 9  ? it used to work with tomat 7

Thanks,
Madhan

Re: Tomcat 9.0 - JDBC URL Help

[Luis Rodríguez Fernández]

Hello Crista,

I do think that you can have more chances of get an answer for this in the
Oracle Community [1]

Anyway this is how our tns entries [2] looks like for our Oracle Databases:

TNS_ENTRY_1_PROD=(
 DESCRIPTION=
  (ADDRESS=
(PROTOCOL=TCP) (HOST=my.host.name.1) (PORT=X) )
  (ADDRESS=
(PROTOCOL=TCP) (HOST=my.host.name.1) (PORT=X) )

(LOAD_BALANCE=off)
  (CONNECT_DATA=

(SERVER=DEDICATED)

(SERVICE_NAME=my.service.name)

(FAILOVER_MODE=

(TYPE=SELECT)

(METHOD=BASIC)

)
  )
)

Hope it helps,

Luis

[1]
https://community.oracle.com/community/groundbreakers/database/general_questions
[2]
https://docs.oracle.com/en/database/oracle/oracle-database/19/dbseg/glossary.html#GUID-8836AF91-6176-4133-BD13-348AF90181CE






El lun., 27 ene. 2020 a las 18:15, Edwards, Crista E
() escribió:

> What is the proper syntax for the URL portion of my JDBC connection when
> using 2 databases? We are on Tomcat 9.0, connecting to an Oracle database.
> We have 2 database instances, one active & one inactive, but the JDBC
> connection must contain both & connect to the active instance. Below is an
> example of the URL we were using when on Websphere servers.
>
> jdbc:oracle:thin:@
> (DESCRIPTION=(ADDRESS_LIST=(source_route=off)(load_balance=off)(failover=on)(address=(protocol=tcp)(host=
> ldb123.prod.exint.net)(port=1500))(address=(protocol=tcp)(host=
> ldb234.prod.exint.net)(port=1500)))(connect_data=(service_name=
> abc0405p_rwsvc.prod.exint.net)))
>
> Thank you,
> Crista Edwards
>
>
>
> The contents of this email are the property of PNC. If it was not
> addressed to you, you have no legal right to read it. If you think you
> received it in error, please notify the sender. Do not forward or copy
> without permission of the sender. This message may be considered a
> commercial electronic message under Canadian law or this message may
> contain an advertisement of a product or service and thus may constitute a
> commercial electronic mail message under US law. You may unsubscribe at any
> time from receiving commercial electronic messages from PNC at
> http://pages.e.pnc.com/globalunsub/
> PNC, 249 Fifth Avenue, Pittsburgh, PA 15222; pnc.com
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 

"Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better."

- Samuel Beckett

Tomcat 9.0 - JDBC URL Help

[Edwards, Crista E]

What is the proper syntax for the URL portion of my JDBC connection when using 
2 databases? We are on Tomcat 9.0, connecting to an Oracle database. We have 2 
database instances, one active & one inactive, but the JDBC connection must 
contain both & connect to the active instance. Below is an example of the URL 
we were using when on Websphere servers.

jdbc:oracle:thin:@(DESCRIPTION=(ADDRESS_LIST=(source_route=off)(load_balance=off)(failover=on)(address=(protocol=tcp)(host=ldb123.prod.exint.net)(port=1500))(address=(protocol=tcp)(host=ldb234.prod.exint.net)(port=1500)))(connect_data=(service_name=abc0405p_rwsvc.prod.exint.net)))

Thank you,
Crista Edwards



The contents of this email are the property of PNC. If it was not addressed to 
you, you have no legal right to read it. If you think you received it in error, 
please notify the sender. Do not forward or copy without permission of the 
sender. This message may be considered a commercial electronic message under 
Canadian law or this message may contain an advertisement of a product or 
service and thus may constitute a commercial electronic mail message under US 
law. You may unsubscribe at any time from receiving commercial electronic 
messages from PNC at http://pages.e.pnc.com/globalunsub/
PNC, 249 Fifth Avenue, Pittsburgh, PA 15222; pnc.com



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

Apache Tomcat 9.0 start error 1067 (4)

[Lars E. Andersen]

Hello Mark

Thank you for your good help, Apache Tomcat 9.0.24 is working with a Hello
World JSP tile now.

I could not find a 9.0.23 installation exe download, but I found
a Apache-tomcat-9.0.20-windows-x64.zip,
which I downloaded and extracted into the C:\Program Files\Apache Software
Foundation folder, but
the Tomcat9w.exe would not start Tomcat.
And as I was not sure how to install Tomcat from a zip-file, so I decided
to unstall / delete everything.

And than I download a new Apache-tomcat-9.0.24.exe and installed it as an
administrator and this time
when I used Tomcat9w.exe Tomcat changed state from Stopped to Started and
my HelloWorld.jsp file
worked in the browser.

Thanks very much for your help.

Kind Regards

Lars E. Andersen

Mobil: 00351 914411785
Email: lea4...@gmail.com



Hmm.

That looks like a 64-bit JRE but the error you are seeing is only seen
with 32-bit JREs.

Can you try installing 9.0.23 and see if that works? If it does you can
simply copy Tomcat9.exe from your 9.0.23 install and replace the version
in 9.0.24 as a work-around.

Mark


Den man. 2. sep. 2019 kl. 22.48 skrev Mark Thomas :

> On 01/09/2019 20:56, Lars E. Andersen wrote:
> > Hello Mark
> >
> > The release text file states:
> > JAVA_VERSION="1.8.0_111"
> >
> > Kind Regards
> >
> > Lars E. Andersen
> >
> >
> > Den søn. 1. sep. 2019 kl. 20.46 skrev Lars E. Andersen <
> lea4...@gmail.com>:
> >
> >> Hello Mark
> >>
> >> My java version is "jdk-8u111-nb-8_2-windows-x64", it was installed on
> the
> >> 25.3.2019.
>
>
>
> >> I do not know if, it has been updated afterwards.
> >>
> >> Kind Regards
> >>
> >> Lars E. Andersen
> >>
> >>
> >> Den søn. 1. sep. 2019 kl. 20.21 skrev Mark Thomas :
> >>
> >>> On 01/09/2019 20:14, Lars E. Andersen wrote:
> >>>> Hello Tomcat Users
> >>>>
> >>>> I have a start up error on my newly installed Tomcat 9.0, the error
> >>>> information is:
> >>>>
> >>>> Windows could not start Apache Tomcat 9.0 Tomcat9 service on
> >>>> Local Computer.
> >>>>
> >>>> Error 1067: The process terminated unexpectedly.
> >>>>
> >>>>
> >>>> My Tomcat version:
> >>>> Apache-tomcat-9.0.24
> >>>>
> >>>> My computer runs:
> >>>> Windows 10 Home x64, Version 1903, OS build 18362.295
> >>>>
> >>>> I hope you can help me to solve this problem.
> >>>
> >>> (Exact) Java version?
> >>>
> >>> 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
>
>

Re: Apache Tomcat 9.0 start error 1067 (3)

[Mark Thomas]

On 01/09/2019 20:56, Lars E. Andersen wrote:
> Hello Mark
> 
> The release text file states:
> JAVA_VERSION="1.8.0_111"
> 
> Kind Regards
> 
> Lars E. Andersen
> 
> 
> Den søn. 1. sep. 2019 kl. 20.46 skrev Lars E. Andersen :
> 
>> Hello Mark
>>
>> My java version is "jdk-8u111-nb-8_2-windows-x64", it was installed on the
>> 25.3.2019.

Hmm.

That looks like a 64-bit JRE but the error you are seeing is only seen
with 32-bit JREs.

Can you try installing 9.0.23 and see if that works? If it does you can
simply copy Tomcat9.exe from your 9.0.23 install and replace the version
in 9.0.24 as a work-around.

Mark


>> I do not know if, it has been updated afterwards.
>>
>> Kind Regards
>>
>> Lars E. Andersen
>>
>>
>> Den søn. 1. sep. 2019 kl. 20.21 skrev Mark Thomas :
>>
>>> On 01/09/2019 20:14, Lars E. Andersen wrote:
>>>> Hello Tomcat Users
>>>>
>>>> I have a start up error on my newly installed Tomcat 9.0, the error
>>>> information is:
>>>>
>>>> Windows could not start Apache Tomcat 9.0 Tomcat9 service on
>>>> Local Computer.
>>>>
>>>> Error 1067: The process terminated unexpectedly.
>>>>
>>>>
>>>> My Tomcat version:
>>>> Apache-tomcat-9.0.24
>>>>
>>>> My computer runs:
>>>> Windows 10 Home x64, Version 1903, OS build 18362.295
>>>>
>>>> I hope you can help me to solve this problem.
>>>
>>> (Exact) Java version?
>>>
>>> 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

Apache Tomcat 9.0 start error 1067 (3)

[Lars E. Andersen]

Hello Mark

The release text file states:
JAVA_VERSION="1.8.0_111"

Kind Regards

Lars E. Andersen


Den søn. 1. sep. 2019 kl. 20.46 skrev Lars E. Andersen :

> Hello Mark
>
> My java version is "jdk-8u111-nb-8_2-windows-x64", it was installed on the
> 25.3.2019.
> I do not know if, it has been updated afterwards.
>
> Kind Regards
>
> Lars E. Andersen
>
>
> Den søn. 1. sep. 2019 kl. 20.21 skrev Mark Thomas :
>
>> On 01/09/2019 20:14, Lars E. Andersen wrote:
>> > Hello Tomcat Users
>> >
>> > I have a start up error on my newly installed Tomcat 9.0, the error
>> > information is:
>> >
>> > Windows could not start Apache Tomcat 9.0 Tomcat9 service on
>> > Local Computer.
>> >
>> > Error 1067: The process terminated unexpectedly.
>> >
>> >
>> > My Tomcat version:
>> > Apache-tomcat-9.0.24
>> >
>> > My computer runs:
>> > Windows 10 Home x64, Version 1903, OS build 18362.295
>> >
>> > I hope you can help me to solve this problem.
>>
>> (Exact) Java version?
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

Apache Tomcat 9.0 start error 1067 (2)

[Lars E. Andersen]

Hello Mark

My java version is "jdk-8u111-nb-8_2-windows-x64", it was installed on the
25.3.2019.
I do not know if, it has been updated afterwards.

Kind Regards

Lars E. Andersen


Den søn. 1. sep. 2019 kl. 20.21 skrev Mark Thomas :

> On 01/09/2019 20:14, Lars E. Andersen wrote:
> > Hello Tomcat Users
> >
> > I have a start up error on my newly installed Tomcat 9.0, the error
> > information is:
> >
> > Windows could not start Apache Tomcat 9.0 Tomcat9 service on
> > Local Computer.
> >
> > Error 1067: The process terminated unexpectedly.
> >
> >
> > My Tomcat version:
> > Apache-tomcat-9.0.24
> >
> > My computer runs:
> > Windows 10 Home x64, Version 1903, OS build 18362.295
> >
> > I hope you can help me to solve this problem.
>
> (Exact) Java version?
>
> Mark
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Apache Tomcat 9.0 start error 1067

[Mark Thomas]

On 01/09/2019 20:14, Lars E. Andersen wrote:
> Hello Tomcat Users
> 
> I have a start up error on my newly installed Tomcat 9.0, the error
> information is:
> 
> Windows could not start Apache Tomcat 9.0 Tomcat9 service on
> Local Computer.
> 
> Error 1067: The process terminated unexpectedly.
> 
> 
> My Tomcat version:
> Apache-tomcat-9.0.24
> 
> My computer runs:
> Windows 10 Home x64, Version 1903, OS build 18362.295
> 
> I hope you can help me to solve this problem.

(Exact) Java version?

Mark


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

Apache Tomcat 9.0 start error 1067

[Lars E. Andersen]

Hello Tomcat Users

I have a start up error on my newly installed Tomcat 9.0, the error
information is:

Windows could not start Apache Tomcat 9.0 Tomcat9 service on
Local Computer.

Error 1067: The process terminated unexpectedly.


My Tomcat version:
Apache-tomcat-9.0.24

My computer runs:
Windows 10 Home x64, Version 1903, OS build 18362.295

I hope you can help me to solve this problem.


Kind Regards

Lars E. Andersen
Lisbon Portugal

Email: lea4...@gmail.com

Re: "Tomcat 9.0.x configuration file differences" broken

[Greg Huber]

for the fortunate, you can use http://meldmerge.org/  ok its local but
works well.

On Wed, 20 Mar 2019 at 09:58, Mark Thomas  wrote:

> On 20/03/2019 06:45, Dirk Gfrörer wrote:
> > Hello,
> >
> > before upgrading our Tomcats I usually check for any changes within the
> > catalina.policy, etc. files.
> >
> > I use this URL
> >
> > https://tomcat.apache.org/migration-9.html
> >
> > scroll down to the very bottom and than click on the "View Differences"
> > button. You get redirected to
> >
> >
> https://gitbox.apache.org/repos/asf?p=tomcat.git&a=blobdiff&f=conf%2Fcatalina.policy&hpb=9.0.16&hb=9.0.17
> >
> >
> > which than shows:
> >
> > Forbidden
> > You don't have permission to access /repos/asf on this server.
> >
> >
> > Same is true for
> > http://tomcat.apache.org/migration-85.html
> >
> > Maybe someone on this list is able to check.
>
> The service that those URLs use has been temporarily disabled by ASF
> infra due to abusive traffic. They hope to be able to re-enable it soon.
> If not, we'll need to find an alternative solution.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: "Tomcat 9.0.x configuration file differences" broken

[Mark Thomas]

On 20/03/2019 06:45, Dirk Gfrörer wrote:
> Hello,
> 
> before upgrading our Tomcats I usually check for any changes within the
> catalina.policy, etc. files.
> 
> I use this URL
> 
> https://tomcat.apache.org/migration-9.html
> 
> scroll down to the very bottom and than click on the "View Differences"
> button. You get redirected to
> 
> https://gitbox.apache.org/repos/asf?p=tomcat.git&a=blobdiff&f=conf%2Fcatalina.policy&hpb=9.0.16&hb=9.0.17
> 
> 
> which than shows:
> 
> Forbidden
> You don't have permission to access /repos/asf on this server.
> 
> 
> Same is true for
> http://tomcat.apache.org/migration-85.html
> 
> Maybe someone on this list is able to check.

The service that those URLs use has been temporarily disabled by ASF
infra due to abusive traffic. They hope to be able to re-enable it soon.
If not, we'll need to find an alternative solution.

Mark

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

"Tomcat 9.0.x configuration file differences" broken

[Dirk Gfrörer]

Hello,

before upgrading our Tomcats I usually check for any changes within the 
catalina.policy, etc. files.


I use this URL

https://tomcat.apache.org/migration-9.html

scroll down to the very bottom and than click on the "View Differences" 
button. You get redirected to


https://gitbox.apache.org/repos/asf?p=tomcat.git&a=blobdiff&f=conf%2Fcatalina.policy&hpb=9.0.16&hb=9.0.17

which than shows:

Forbidden
You don't have permission to access /repos/asf on this server.


Same is true for
http://tomcat.apache.org/migration-85.html

Maybe someone on this list is able to check.

Kind Regards,
DirK Gfrörer

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

Re: Tomcat 9.0 with security manager reports access denied

[Kai Hofmann]

Am 25.01.2019 um 21:58 schrieb Mark Thomas:
> On 25/01/2019 20:34, Mark Thomas wrote:
>> On 25/01/2019 11:12, Mark Thomas wrote:
>>> On 24/01/2019 12:19, Kai Hofmann wrote:
>>>> Hello,
>>>>
>>>> I try to activate the security manager for my own Application within
>>>> Tomcat 9.0.x. The problem ist that I got 2 different access denied's
>>>> that should (from my point of view) not happen. So this might be a bug -
>>>> but I am not 100% sure.
>>>>
>>>> To make a long story short I have put all information into a
>>>> stackoverflow question:
>>>>
>>>> https://stackoverflow.com/questions/54254003/tomcat-9-0-with-security-manager-reports-access-denied
>>>>
>>>> Maybe someone could help me with this problem?
>>>
>>> Strange.
>>>
>>> The failures might be related to running as a Windows service but I
>>> don't immediately see how. I wonder if there is a configuration issue.
>>>
>>> I ran a similar test locally on Linux and I don't see those failures. I
>>> did see a couple of other minor issues that I am in the process of fixing.
>>>
>>> Once I've finished fixing the issues I can see on Linux, I'll install
>>> the latest 9.0.x code as a Windows service and see if I can reproduce
>>> any of those failures.
>>
>> I see some additional instances of "denied" but not the ones you saw,
>>
>> I did notice that the security policy file was not configured correctly.
>> "==" is required when setting catalina.policy
>>
>> I'll look into getting the additional failures I've observed fixed but
>> it would help if you could provide the steps to reproduce the failures
>> you see from a clean Tomcat install.
> 
> The additional failures are expected. java.beans.Introspector is trying
> to load classes that don't exist and they fail.
> 
> Mark
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 

Dear Mark,

thanks for the hint with the '==' for the catalina.policy definition.
This fixed one of my exceptions.

The seconds exception could then be fixed with adding

permission java.util.PropertyPermission
"org.apache.juli.logging.UserDataHelper.CONFIG", "read";

to the policies.

So every thing works here on windows as service ;-)

Greetings

  PowerStat


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

Re: Tomcat 9.0 with security manager reports access denied

[Mark Thomas]

On 25/01/2019 20:34, Mark Thomas wrote:
> On 25/01/2019 11:12, Mark Thomas wrote:
>> On 24/01/2019 12:19, Kai Hofmann wrote:
>>> Hello,
>>>
>>> I try to activate the security manager for my own Application within
>>> Tomcat 9.0.x. The problem ist that I got 2 different access denied's
>>> that should (from my point of view) not happen. So this might be a bug -
>>> but I am not 100% sure.
>>>
>>> To make a long story short I have put all information into a
>>> stackoverflow question:
>>>
>>> https://stackoverflow.com/questions/54254003/tomcat-9-0-with-security-manager-reports-access-denied
>>>
>>> Maybe someone could help me with this problem?
>>
>> Strange.
>>
>> The failures might be related to running as a Windows service but I
>> don't immediately see how. I wonder if there is a configuration issue.
>>
>> I ran a similar test locally on Linux and I don't see those failures. I
>> did see a couple of other minor issues that I am in the process of fixing.
>>
>> Once I've finished fixing the issues I can see on Linux, I'll install
>> the latest 9.0.x code as a Windows service and see if I can reproduce
>> any of those failures.
> 
> I see some additional instances of "denied" but not the ones you saw,
> 
> I did notice that the security policy file was not configured correctly.
> "==" is required when setting catalina.policy
> 
> I'll look into getting the additional failures I've observed fixed but
> it would help if you could provide the steps to reproduce the failures
> you see from a clean Tomcat install.

The additional failures are expected. java.beans.Introspector is trying
to load classes that don't exist and they fail.

Mark

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

Re: Tomcat 9.0 with security manager reports access denied

[Mark Thomas]

On 25/01/2019 11:12, Mark Thomas wrote:
> On 24/01/2019 12:19, Kai Hofmann wrote:
>> Hello,
>>
>> I try to activate the security manager for my own Application within
>> Tomcat 9.0.x. The problem ist that I got 2 different access denied's
>> that should (from my point of view) not happen. So this might be a bug -
>> but I am not 100% sure.
>>
>> To make a long story short I have put all information into a
>> stackoverflow question:
>>
>> https://stackoverflow.com/questions/54254003/tomcat-9-0-with-security-manager-reports-access-denied
>>
>> Maybe someone could help me with this problem?
> 
> Strange.
> 
> The failures might be related to running as a Windows service but I
> don't immediately see how. I wonder if there is a configuration issue.
> 
> I ran a similar test locally on Linux and I don't see those failures. I
> did see a couple of other minor issues that I am in the process of fixing.
> 
> Once I've finished fixing the issues I can see on Linux, I'll install
> the latest 9.0.x code as a Windows service and see if I can reproduce
> any of those failures.

I see some additional instances of "denied" but not the ones you saw,

I did notice that the security policy file was not configured correctly.
"==" is required when setting catalina.policy

I'll look into getting the additional failures I've observed fixed but
it would help if you could provide the steps to reproduce the failures
you see from a clean Tomcat install.

Mark

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

Re: Tomcat 9.0 with security manager reports access denied

[Mark Thomas]

On 24/01/2019 12:19, Kai Hofmann wrote:
> Hello,
> 
> I try to activate the security manager for my own Application within
> Tomcat 9.0.x. The problem ist that I got 2 different access denied's
> that should (from my point of view) not happen. So this might be a bug -
> but I am not 100% sure.
> 
> To make a long story short I have put all information into a
> stackoverflow question:
> 
> https://stackoverflow.com/questions/54254003/tomcat-9-0-with-security-manager-reports-access-denied
> 
> Maybe someone could help me with this problem?

Strange.

The failures might be related to running as a Windows service but I
don't immediately see how. I wonder if there is a configuration issue.

I ran a similar test locally on Linux and I don't see those failures. I
did see a couple of other minor issues that I am in the process of fixing.

Once I've finished fixing the issues I can see on Linux, I'll install
the latest 9.0.x code as a Windows service and see if I can reproduce
any of those failures.

Mark

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

Tomcat 9.0 with security manager reports access denied

[Kai Hofmann]

Hello,

I try to activate the security manager for my own Application within
Tomcat 9.0.x. The problem ist that I got 2 different access denied's
that should (from my point of view) not happen. So this might be a bug -
but I am not 100% sure.

To make a long story short I have put all information into a
stackoverflow question:

https://stackoverflow.com/questions/54254003/tomcat-9-0-with-security-manager-reports-access-denied

Maybe someone could help me with this problem?

Thanks in advance

  Kai

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

Re: Java 11 support in Apache Tomcat 9.0

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Shailendra,

On 9/26/18 10:19, Shailendra Kumar Verma wrote:
> Okay, so we have to provide root of jdk11 install when prompted at
> time of installation.
> 
> Since JDK includes compiler and PCI compliance does not allow it.

Can you please provide a reference to that PCI item?

Thanks,
- -chris

> -Original Message- From: Mark Thomas  
> Sent: Wednesday, September 26, 2018 7:36 PM To:
> users@tomcat.apache.org Subject: Re: Java 11 support in Apache
> Tomcat 9.0
> 
> ***CAUTION: This email originated from outside of the organization.
> Do not open attachments or click links unless you recognize sender
> and know content is safe.*** Forward suspicious email to
> suspici...@convergys.com
> ___
>
>  Tomcat already supports Java 11 and has done for some time.
> 
> You need to point the installer to the root of the jdk-11 install.
> 
> If you install the Orcale JDK, the installer will find it via the
> registry. If you use OpenJDK you'll need to select the root of the
> install (a.k.a. JAVA_HOME) yourself.
> 
> Mark
> 
> 
> 
> On 26/09/2018 08:01, Shailendra Kumar Verma wrote:
>> Johan,
>> 
>> That's what I am saying. All we have now, jvm.dll that comes
>> under jdk-11\bin\server\jvm.dll. No JRE is released from Java 11
>> now.
>> 
>> Thanks, Shailendra
>> 
>> -Original Message----- From: Johan Compagner
>>  Sent: Wednesday, September 26, 2018 5:28
>> PM To: Tomcat Users List  Subject: Re:
>> Java 11 support in Apache Tomcat 9.0
>> 
>> ***CAUTION: This email originated from outside of the
>> organization. Do not open attachments or click links unless you
>> recognize sender and know content is safe.*** Forward suspicious
>> email to suspici...@convergys.com 
>> ___
>>
>>
>> 
Just wondering how do you get a JRE?
>> oracle doesnt provide one anymore (and the JDK that you can
>> download can only really be used for development and nothing
>> else)
>> 
>> so are you using the open source JDK?
>> 
>> 
>> On Wed, 26 Sep 2018 at 13:40, Shailendra Kumar Verma <
>> shailendra.kumar.ve...@convergys.com> wrote:
>> 
>>> Hello,
>>> 
>>> When we run Tomcat 9.0.12 installer, it prompts to provide JRE
>>> location. Since Java 11 LTS release yesterday does NOT have any
>>> JRE installer separately, all it has server JVM embedded in it
>>> under . If I give this path where jvm.dll
>>> located under server folder, it does not recognize.
>>> 
>>> Whats' the plan for Java 11 for Apache Tomcat 9.0?
>>> 
>>> Thanks, Shailendra
>>> 
>>> NOTICE: The information contained in this electronic mail 
>>> transmission is intended by Convergys Corporation for the use
>>> of the named individual or entity to which it is directed and
>>> may contain information that is privileged or otherwise
>>> confidential. If you have received this electronic mail
>>> transmission in error, please delete it from your system
>>> without copying or forwarding it, and notify the sender of the
>>> error by reply email or by telephone (collect), so that the
>>> sender's address records can be corrected.
>>> 
>> 
>> 
>> -- Johan Compagner Servoy NOTICE: The information contained in
>> this electronic mail transmission is intended by Convergys
>> Corporation for the use of the named individual or entity to
>> which it is directed and may contain information that is
>> privileged or otherwise confidential. If you have received this
>> electronic mail transmission in error, please delete it from your
>> system without copying or forwarding it, and notify the sender of
>> the error by reply email or by telephone (collect), so that the
>> sender's address records can be corrected.
>> 
>> -
>>
>> 
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
> 
> NOTICE: The information contained in this electronic mail
> transmission is intended by Convergys Corporation for the use of
> the named individual or entity to whic

Re: Java 11 support in Apache Tomcat 9.0

[Johan Compagner]

but if you talk about a jlink thing isn't it then the idea that it it
includes it all so including tomcat and maybe even the webapp that you want
to run on it?


On Wed, 26 Sep 2018 at 16:19, Shailendra Kumar Verma <
shailendra.kumar.ve...@convergys.com> wrote:

> Okay, so we have to provide root of jdk11 install when prompted at time of
> installation.
>
> Since JDK includes compiler and PCI compliance does not allow it. What if
> we install custom runtime using "jlink" instead of "full JDK11? Will Apache
> Tomcat gets install if we give path of jlink installed custom runtime that
> includes jvm.dll?
>
> Thanks,
> Shailendra
>
>
> -Original Message-
> From: Mark Thomas 
> Sent: Wednesday, September 26, 2018 7:36 PM
> To: users@tomcat.apache.org
> Subject: Re: Java 11 support in Apache Tomcat 9.0
>
> ***CAUTION: This email originated from outside of the organization. Do not
> open attachments or click links unless you recognize sender and know
> content is safe.*** Forward suspicious email to suspici...@convergys.com
> ___
>
> Tomcat already supports Java 11 and has done for some time.
>
> You need to point the installer to the root of the jdk-11 install.
>
> If you install the Orcale JDK, the installer will find it via the
> registry. If you use OpenJDK you'll need to select the root of the install
> (a.k.a. JAVA_HOME) yourself.
>
> Mark
>
>
>
> On 26/09/2018 08:01, Shailendra Kumar Verma wrote:
> > Johan,
> >
> > That's what I am saying. All we have now, jvm.dll that comes under
> jdk-11\bin\server\jvm.dll. No JRE is released from Java 11 now.
> >
> > Thanks,
> > Shailendra
> >
> > -Original Message-
> > From: Johan Compagner 
> > Sent: Wednesday, September 26, 2018 5:28 PM
> > To: Tomcat Users List 
> > Subject: Re: Java 11 support in Apache Tomcat 9.0
> >
> > ***CAUTION: This email originated from outside of the organization. Do
> > not open attachments or click links unless you recognize sender and
> > know content is safe.*** Forward suspicious email to
> > suspici...@convergys.com
> > ___
> >
> > Just wondering how do you get a JRE?
> > oracle doesnt provide one anymore (and the JDK that you can download
> > can only really be used for development and nothing else)
> >
> > so are you using the open source JDK?
> >
> >
> > On Wed, 26 Sep 2018 at 13:40, Shailendra Kumar Verma <
> shailendra.kumar.ve...@convergys.com> wrote:
> >
> >> Hello,
> >>
> >> When we run Tomcat 9.0.12 installer, it prompts to provide JRE location.
> >> Since Java 11 LTS release yesterday does NOT have any JRE installer
> >> separately, all it has server JVM embedded in it under
> .
> >> If I give this path where jvm.dll located under server folder, it
> >> does not recognize.
> >>
> >> Whats' the plan for Java 11 for Apache Tomcat 9.0?
> >>
> >> Thanks,
> >> Shailendra
> >>
> >> NOTICE: The information contained in this electronic mail
> >> transmission is intended by Convergys Corporation for the use of the
> >> named individual or entity to which it is directed and may contain
> >> information that is privileged or otherwise confidential. If you have
> >> received this electronic mail transmission in error, please delete it
> >> from your system without copying or forwarding it, and notify the
> >> sender of the error by reply email or by telephone (collect), so that
> >> the sender's address records can be corrected.
> >>
> >
> >
> > --
> > Johan Compagner
> > Servoy
> > NOTICE: The information contained in this electronic mail transmission
> is intended by Convergys Corporation for the use of the named individual or
> entity to which it is directed and may contain information that is
> privileged or otherwise confidential. If you have received this electronic
> mail transmission in error, please delete it from your system without
> copying or forwarding it, and notify the sender of the error by reply email
> or by telephone (collect), so that the sender's address records can be
> corrected.
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
>
> 

RE: Java 11 support in Apache Tomcat 9.0

[Shailendra Kumar Verma]

Okay, so we have to provide root of jdk11 install when prompted at time of 
installation.

Since JDK includes compiler and PCI compliance does not allow it. What if we 
install custom runtime using "jlink" instead of "full JDK11? Will Apache Tomcat 
gets install if we give path of jlink installed custom runtime that includes 
jvm.dll?

Thanks,
Shailendra


-Original Message-
From: Mark Thomas 
Sent: Wednesday, September 26, 2018 7:36 PM
To: users@tomcat.apache.org
Subject: Re: Java 11 support in Apache Tomcat 9.0

***CAUTION: This email originated from outside of the organization. Do not open 
attachments or click links unless you recognize sender and know content is 
safe.*** Forward suspicious email to suspici...@convergys.com 
___

Tomcat already supports Java 11 and has done for some time.

You need to point the installer to the root of the jdk-11 install.

If you install the Orcale JDK, the installer will find it via the registry. If 
you use OpenJDK you'll need to select the root of the install (a.k.a. 
JAVA_HOME) yourself.

Mark



On 26/09/2018 08:01, Shailendra Kumar Verma wrote:
> Johan,
>
> That's what I am saying. All we have now, jvm.dll that comes under 
> jdk-11\bin\server\jvm.dll. No JRE is released from Java 11 now.
>
> Thanks,
> Shailendra
>
> -Original Message-
> From: Johan Compagner 
> Sent: Wednesday, September 26, 2018 5:28 PM
> To: Tomcat Users List 
> Subject: Re: Java 11 support in Apache Tomcat 9.0
>
> ***CAUTION: This email originated from outside of the organization. Do
> not open attachments or click links unless you recognize sender and
> know content is safe.*** Forward suspicious email to
> suspici...@convergys.com
> ___
>
> Just wondering how do you get a JRE?
> oracle doesnt provide one anymore (and the JDK that you can download
> can only really be used for development and nothing else)
>
> so are you using the open source JDK?
>
>
> On Wed, 26 Sep 2018 at 13:40, Shailendra Kumar Verma < 
> shailendra.kumar.ve...@convergys.com> wrote:
>
>> Hello,
>>
>> When we run Tomcat 9.0.12 installer, it prompts to provide JRE location.
>> Since Java 11 LTS release yesterday does NOT have any JRE installer
>> separately, all it has server JVM embedded in it under .
>> If I give this path where jvm.dll located under server folder, it
>> does not recognize.
>>
>> Whats' the plan for Java 11 for Apache Tomcat 9.0?
>>
>> Thanks,
>> Shailendra
>>
>> NOTICE: The information contained in this electronic mail
>> transmission is intended by Convergys Corporation for the use of the
>> named individual or entity to which it is directed and may contain
>> information that is privileged or otherwise confidential. If you have
>> received this electronic mail transmission in error, please delete it
>> from your system without copying or forwarding it, and notify the
>> sender of the error by reply email or by telephone (collect), so that
>> the sender's address records can be corrected.
>>
>
>
> --
> Johan Compagner
> Servoy
> NOTICE: The information contained in this electronic mail transmission is 
> intended by Convergys Corporation for the use of the named individual or 
> entity to which it is directed and may contain information that is privileged 
> or otherwise confidential. If you have received this electronic mail 
> transmission in error, please delete it from your system without copying or 
> forwarding it, and notify the sender of the error by reply email or by 
> telephone (collect), so that the sender's address records can be corrected.
>
> -
> 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

NOTICE: The information contained in this electronic mail transmission is 
intended by Convergys Corporation for the use of the named individual or entity 
to which it is directed and may contain information that is privileged or 
otherwise confidential. If you have received this electronic mail transmission 
in error, please delete it from your system without copying or forwarding it, 
and notify the sender of the error by reply email or by telephone (collect), so 
that the sender's address records can be corrected.

Re: Java 11 support in Apache Tomcat 9.0

[Mark Thomas]

Tomcat already supports Java 11 and has done for some time.

You need to point the installer to the root of the jdk-11 install.

If you install the Orcale JDK, the installer will find it via the 
registry. If you use OpenJDK you'll need to select the root of the 
install (a.k.a. JAVA_HOME) yourself.


Mark



On 26/09/2018 08:01, Shailendra Kumar Verma wrote:

Johan,

That's what I am saying. All we have now, jvm.dll that comes under 
jdk-11\bin\server\jvm.dll. No JRE is released from Java 11 now.

Thanks,
Shailendra

-Original Message-
From: Johan Compagner 
Sent: Wednesday, September 26, 2018 5:28 PM
To: Tomcat Users List 
Subject: Re: Java 11 support in Apache Tomcat 9.0

***CAUTION: This email originated from outside of the organization. Do not open 
attachments or click links unless you recognize sender and know content is 
safe.*** Forward suspicious email to suspici...@convergys.com 
___

Just wondering how do you get a JRE?
oracle doesnt provide one anymore (and the JDK that you can download can only 
really be used for development and nothing else)

so are you using the open source JDK?


On Wed, 26 Sep 2018 at 13:40, Shailendra Kumar Verma < 
shailendra.kumar.ve...@convergys.com> wrote:


Hello,

When we run Tomcat 9.0.12 installer, it prompts to provide JRE location.
Since Java 11 LTS release yesterday does NOT have any JRE installer
separately, all it has server JVM embedded in it under .
If I give this path where jvm.dll located under server folder, it does
not recognize.

Whats' the plan for Java 11 for Apache Tomcat 9.0?

Thanks,
Shailendra

NOTICE: The information contained in this electronic mail transmission
is intended by Convergys Corporation for the use of the named
individual or entity to which it is directed and may contain
information that is privileged or otherwise confidential. If you have
received this electronic mail transmission in error, please delete it
from your system without copying or forwarding it, and notify the
sender of the error by reply email or by telephone (collect), so that
the sender's address records can be corrected.




--
Johan Compagner
Servoy
NOTICE: The information contained in this electronic mail transmission is 
intended by Convergys Corporation for the use of the named individual or entity 
to which it is directed and may contain information that is privileged or 
otherwise confidential. If you have received this electronic mail transmission 
in error, please delete it from your system without copying or forwarding it, 
and notify the sender of the error by reply email or by telephone (collect), so 
that the sender's address records can be corrected.

-
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: Java 11 support in Apache Tomcat 9.0

[Shailendra Kumar Verma]

Johan,

That's what I am saying. All we have now, jvm.dll that comes under 
jdk-11\bin\server\jvm.dll. No JRE is released from Java 11 now.

Thanks,
Shailendra

-Original Message-
From: Johan Compagner 
Sent: Wednesday, September 26, 2018 5:28 PM
To: Tomcat Users List 
Subject: Re: Java 11 support in Apache Tomcat 9.0

***CAUTION: This email originated from outside of the organization. Do not open 
attachments or click links unless you recognize sender and know content is 
safe.*** Forward suspicious email to suspici...@convergys.com 
___

Just wondering how do you get a JRE?
oracle doesnt provide one anymore (and the JDK that you can download can only 
really be used for development and nothing else)

so are you using the open source JDK?


On Wed, 26 Sep 2018 at 13:40, Shailendra Kumar Verma < 
shailendra.kumar.ve...@convergys.com> wrote:

> Hello,
>
> When we run Tomcat 9.0.12 installer, it prompts to provide JRE location.
> Since Java 11 LTS release yesterday does NOT have any JRE installer
> separately, all it has server JVM embedded in it under .
> If I give this path where jvm.dll located under server folder, it does
> not recognize.
>
> Whats' the plan for Java 11 for Apache Tomcat 9.0?
>
> Thanks,
> Shailendra
>
> NOTICE: The information contained in this electronic mail transmission
> is intended by Convergys Corporation for the use of the named
> individual or entity to which it is directed and may contain
> information that is privileged or otherwise confidential. If you have
> received this electronic mail transmission in error, please delete it
> from your system without copying or forwarding it, and notify the
> sender of the error by reply email or by telephone (collect), so that
> the sender's address records can be corrected.
>


--
Johan Compagner
Servoy
NOTICE: The information contained in this electronic mail transmission is 
intended by Convergys Corporation for the use of the named individual or entity 
to which it is directed and may contain information that is privileged or 
otherwise confidential. If you have received this electronic mail transmission 
in error, please delete it from your system without copying or forwarding it, 
and notify the sender of the error by reply email or by telephone (collect), so 
that the sender's address records can be corrected.

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

Re: Java 11 support in Apache Tomcat 9.0

[Johan Compagner]

Just wondering how do you get a JRE?
oracle doesnt provide one anymore (and the JDK that you can download can
only really be used for development and nothing else)

so are you using the open source JDK?


On Wed, 26 Sep 2018 at 13:40, Shailendra Kumar Verma <
shailendra.kumar.ve...@convergys.com> wrote:

> Hello,
>
> When we run Tomcat 9.0.12 installer, it prompts to provide JRE location.
> Since Java 11 LTS release yesterday does NOT have any JRE installer
> separately, all it has server JVM embedded in it under .
> If I give this path where jvm.dll located under server folder, it does not
> recognize.
>
> Whats' the plan for Java 11 for Apache Tomcat 9.0?
>
> Thanks,
> Shailendra
>
> NOTICE: The information contained in this electronic mail transmission is
> intended by Convergys Corporation for the use of the named individual or
> entity to which it is directed and may contain information that is
> privileged or otherwise confidential. If you have received this electronic
> mail transmission in error, please delete it from your system without
> copying or forwarding it, and notify the sender of the error by reply email
> or by telephone (collect), so that the sender's address records can be
> corrected.
>


-- 
Johan Compagner
Servoy

Java 11 support in Apache Tomcat 9.0

[Shailendra Kumar Verma]

Hello,

When we run Tomcat 9.0.12 installer, it prompts to provide JRE location. Since 
Java 11 LTS release yesterday does NOT have any JRE installer separately, all 
it has server JVM embedded in it under . If I give this path 
where jvm.dll located under server folder, it does not recognize.

Whats' the plan for Java 11 for Apache Tomcat 9.0?

Thanks,
Shailendra

NOTICE: The information contained in this electronic mail transmission is 
intended by Convergys Corporation for the use of the named individual or entity 
to which it is directed and may contain information that is privileged or 
otherwise confidential. If you have received this electronic mail transmission 
in error, please delete it from your system without copying or forwarding it, 
and notify the sender of the error by reply email or by telephone (collect), so 
that the sender's address records can be corrected.

Re: Can i use tomcat 9.0.x version in production

[s v n trimurthulu]

Thanks Mark and Christopher

On Wed, Oct 4, 2017 at 6:12 AM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Murthy,
>
> On 10/3/17 7:38 AM, s v n trimurthulu wrote:
> > At present we are using 7.0.x in our production environment. As we
> > have received few CVE alerts we wanted to migrate it to latest
> > version 9.0.x. But when i see the status of the 9.0.x release it is
> > showing "Stable = No". So i request you to suggest me whether i
> > can use the latest version(9.0.1) of tomcat in production or not.
> > Thanks in advance.
>
> I'd recommend moving towards Tomcat 8.5 (after extensive testing in an
> appropriate environment). There are very few differences between 8.5
> and 9.0 (other than Servlet Spec changes) and so moving from 8.5 ->
> 9.0 in the future should be fairly easy.
>
> Tomcat 8.5 *is* currently considered production-ready.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULoIdHGNocmlzQGNo
> cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhEWw//bpMgdIQCx11yDxUZ
> a1TxW8C3jqzKrTJdF1qbWmlZRIVt0kL8gryU8YGtPEP2Ge0c7uf6uqIIwsSJAPKO
> VoJhHwXe9lQWjZL4EUxzK9w+uU77Kl/C4kroojz2PiNS2CTeYOcrw6dfTmFdAMhY
> KAHMnl6oxp/mwf2s5DW9E7XZ/E+6Y+Ovr1gNIZ5u0qZHSRDJhimsfiTQfaQ2JnuS
> hORk/M1toaatDX0YiMXdyXIsWjDN4i+GpUvmIZheOP2SZauvyBCcCsL+OEEfWWSL
> lFvJHCLBkGxGzjN9lIIISi/EYnhZa2xhPpGpr9UjbDLIip898nB/5JBPEgVaBfvu
> lcCIzYJhfQpAwj2R0huY0P5NS0z1fUwnrhHntJpN0B/wXkkaBBuBc011MGl+1V0w
> 5GGGrPUhgHKxumWxR+VUn4ZUWL4jvg6V3lGx5i/GY0M4wjjlpZCIGBP+6Cg+CFD4
> zhYQOre3IAFnb+CmJZhTXpp2kjjjgrDUcHLyjLWvcdl8JFLsBmWIqOvPBZvAbjN3
> zWYg/GOis/obJ7quBlL/z0E2E2RI0yacuQ5sxO1z6HPbMFaQ9OIAjY0yEFZG+qlo
> MuMVnckGpdiDdE+StUZcUHExpX+PXONL6VmT55m8lOrMjvQK5w/qtb5NPkgWM+ZO
> Ys4yaxBShFtkVdAOlOAzYKGtmAs=
> =7W8F
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Can i use tomcat 9.0.x version in production

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Murthy,

On 10/3/17 7:38 AM, s v n trimurthulu wrote:
> At present we are using 7.0.x in our production environment. As we
> have received few CVE alerts we wanted to migrate it to latest
> version 9.0.x. But when i see the status of the 9.0.x release it is
> showing "Stable = No". So i request you to suggest me whether i
> can use the latest version(9.0.1) of tomcat in production or not.
> Thanks in advance.

I'd recommend moving towards Tomcat 8.5 (after extensive testing in an
appropriate environment). There are very few differences between 8.5
and 9.0 (other than Servlet Spec changes) and so moving from 8.5 ->
9.0 in the future should be fairly easy.

Tomcat 8.5 *is* currently considered production-ready.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlnULoIdHGNocmlzQGNo
cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFhEWw//bpMgdIQCx11yDxUZ
a1TxW8C3jqzKrTJdF1qbWmlZRIVt0kL8gryU8YGtPEP2Ge0c7uf6uqIIwsSJAPKO
VoJhHwXe9lQWjZL4EUxzK9w+uU77Kl/C4kroojz2PiNS2CTeYOcrw6dfTmFdAMhY
KAHMnl6oxp/mwf2s5DW9E7XZ/E+6Y+Ovr1gNIZ5u0qZHSRDJhimsfiTQfaQ2JnuS
hORk/M1toaatDX0YiMXdyXIsWjDN4i+GpUvmIZheOP2SZauvyBCcCsL+OEEfWWSL
lFvJHCLBkGxGzjN9lIIISi/EYnhZa2xhPpGpr9UjbDLIip898nB/5JBPEgVaBfvu
lcCIzYJhfQpAwj2R0huY0P5NS0z1fUwnrhHntJpN0B/wXkkaBBuBc011MGl+1V0w
5GGGrPUhgHKxumWxR+VUn4ZUWL4jvg6V3lGx5i/GY0M4wjjlpZCIGBP+6Cg+CFD4
zhYQOre3IAFnb+CmJZhTXpp2kjjjgrDUcHLyjLWvcdl8JFLsBmWIqOvPBZvAbjN3
zWYg/GOis/obJ7quBlL/z0E2E2RI0yacuQ5sxO1z6HPbMFaQ9OIAjY0yEFZG+qlo
MuMVnckGpdiDdE+StUZcUHExpX+PXONL6VmT55m8lOrMjvQK5w/qtb5NPkgWM+ZO
Ys4yaxBShFtkVdAOlOAzYKGtmAs=
=7W8F
-END PGP SIGNATURE-

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

Re: Can i use tomcat 9.0.x version in production

[Mark Thomas]

On 03/10/17 12:38, s v n trimurthulu wrote:
> Hello There,
> 
> At present we are using 7.0.x in our production environment. As we have
> received few CVE alerts we wanted to migrate it to latest version 9.0.x.

I'm not sure if you look at the vulnerability data for the last 12
months that the evidence is there to support that conclusion.

> But when i see the status of the 9.0.x release it is showing "Stable =
> No". So i request you to suggest me whether i  can use the latest
> version(9.0.1) of tomcat in production or not. Thanks in advance.

What you use in production is entirely up to you.

The Tomcat community isn't yet ready to recommend using 9.0.x in
production. How quickly the community is ready to make that
recommendation will depend on the feedback we get on the beta releases.

I'd suggest that you start testing 9.0.x, report and bugs you find and
plan to move to 9.0.x once those bugs have been fixed and the Tomcat
community has declared 9.0.x stable.

Mark

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

Can i use tomcat 9.0.x version in production

[s v n trimurthulu]

Hello There,

At present we are using 7.0.x in our production environment. As we have
received few CVE alerts we wanted to migrate it to latest version 9.0.x.
But when i see the status of the 9.0.x release it is showing "Stable = No".
So i request you to suggest me whether i  can use the latest version(9.0.1)
of tomcat in production or not. Thanks in advance.

[image: Inline image 1]



Regards,
Murthy