Multiple SSL certificates on same server

[Richard Huntrods]

Does anyone know if it is possible, or has anyone done this:

I have two applications running on a single server. The applications use 
different domains and URLs, so the single Tomcat instance can easily 
tell them apart. (Note: this part is currently working just fine).


https://domain1/application1
https://domain2/application2

Again, both domains point to the same static IP, and yes, it is possible 
for someone to access either application from either domain. Normally, 
that is not an issue with the clients.


However, I currently have only one SSL certificate on the server - this 
is for domain1. So if you use domain1 to access application1, it's all 
fine. The security cert comes up green and all that.


BUT - if you try and access application2 via domain2, you get the red 
security cert (wrong domain / server name). I would like to purchase a 
second certificate for the second domain, and am wondering if this can 
be done, and how one would tell Tomcat (in server.xml) to acknowledge 
the second certificate.


Currently the stuff in server.xml looks like this:

  Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
  maxThreads=150 enableLookups=false scheme=https 
secure=true

  keystoreFile=./keys/.keystore keystorePass=myPassword
  clientAuth=false sslProtocol=TLS /


I have a bad feeling it's not possible, but wanted to ask anyway.

Thanks in advance.

-R

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

RE: Multiple SSL certificates on same server

[Richard Huntrods]

On 03/08/2010 06:46 PM, Richard Huntrods wrote:

Does anyone know if it is possible, or has anyone done this:

I have two applications running on a single server. The applications 
use different domains and URLs, so the single Tomcat instance can 
easily tell them apart. (Note: this part is currently working just fine).


https://domain1/application1
https://domain2/application2

Again, both domains point to the same static IP, and yes, it is 
possible for someone to access either application from either domain. 
Normally, that is not an issue with the clients.


However, I currently have only one SSL certificate on the server - 
this is for domain1. So if you use domain1 to access application1, 
it's all fine. The security cert comes up green and all that.


BUT - if you try and access application2 via domain2, you get the red 
security cert (wrong domain / server name). I would like to purchase a 
second certificate for the second domain, and am wondering if this can 
be done, and how one would tell Tomcat (in server.xml) to acknowledge 
the second certificate.


Currently the stuff in server.xml looks like this:

Connector port=443 protocol=HTTP/1.1 SSLEnabled=true
  maxThreads=150 enableLookups=false scheme=https 
secure=true

  keystoreFile=./keys/.keystore keystorePass=myPassword
  clientAuth=false sslProtocol=TLS /


I have a bad feeling it's not possible, but wanted to ask anyway.

Thanks in advance.

-R


~~~

No. 


The certificate is sent and SSL negotiated prior to the server receiving the 
Host header.

~~~

Richard,

It's possible.

It doesn't appear that Tomcat or Java(SUN) support RFC 3546 just yet 
(For Server Name Indication) even though Apache httpd does. However 
Windows XP users of IE will not be able to take advantage of SNI at this 
time anyway (to further rain on your parade). Vista and greater do make 
use of SNI though. Gotta wait for XP to die I guess. :-P


End result: Multi-Domain Certificate, separate ports, separate IPs or a 
load balancer that distributes the load to an internal IP based on FQDN, 
to which you could then use X amount of different SSL certs.(This last 
bit may be a wee bit complicated)


Hope this helps

~~

Hi,


Here's an idea for you:
You can use wildcard when generating your certificate, like *.domain.com,
assuming your servers using same domain.com.

Regards,
Leon Kolchinsky


~~~
Thanks to all of you for your replies.

I fear that Jason is correct for my case.

I'm not using XP, but a Unix server OS, and my domains are radically 
different - so the wildcard cert won't work either. sigh


Cheers,

-R

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

Re: how to upgrade tomcat 8.5.x?

[Richard Huntrods]

On 16/05/2017 17:18, Igal @ Lucee.org wrote:

On 5/16/2017 8:27 AM, Kreuser, Peter wrote:


I'd say a more robust (and the documented way) is to use a 
Tomcat-Home directory and a Tomcat-Base Directory.


$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" 
(ZIP/TGZ),

$CATALINA_BASE holds your adapted config, libs and webapps.

This way you can just exchange the CATALINA_HOME with a new version 
(say 8.5.15) and restart Tomcat. In case there are differences in 
configs between versions, adapt your conf using 
https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences 



I agree that separating the CATALINA_HOME from CATALINA_BASE is a 
much better setup, but if Tomcat was not set up like that already 
then for a minor upgrade this complicates the process.


The simplest way to upgrade is the one I documented.


That simple approach is incomplete. It assumes that:
a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.

a) sometimes happens

b) happens when the JDT compiler is updated

c) can be checked via the migration guides

Mark



Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The 
complex way is to create a new tomcat directory for the new version, 
then rename webapps to webapps.orig and create a new webapps directory 
to hold my war files. Then compare all the config files and make 
appropriate changes to the stock config files, then test. This takes a 
while.


So for the minor change from 12 to 14, I decided to try a new way. On my 
windows devel box, I unzipped a new download of 12 and a new download of 
14 into their own new directories, then compared all the files in both 
(yay for the ancient program "windiff").  I then built a batch file to 
copy only the changed files and tested this. Once satisfied, I built a 
shell script to make the same changes on my devel unix server, and 
tested this. Once I was sure it worked without any problems, I ported 
the script (and virgin 8.5.14 directory) to my production servers. On 
scheduled maintenance I shut down each tomcat 12, ran the script and 
then restarted tomcat. All worked perfectly.


Here's the file changes from 8.5.12 to 8.5.14, no including the changes 
to "webapps" which I don't use:



#!/bin/sh
#
# update files in tomcat 8.5.12 to 8.5.14
#
# when done, rename apache-tomcat-8.5.12 to apache-tomcat-8.5.14
# then fix the symbolic link and restart tomcat
#

cp ./apache-tomcat-8.5.14/RELEASE-NOTES ../apps/apache-tomcat-8.5.12
cp ./apache-tomcat-8.5.14/bin/bootstrap.jar 
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/bin/tomcat-juli.jar 
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/lib/annotations-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ant.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ha.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-tribes.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/el-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper-el.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/jasper.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jaspic-api.jar 
../apps/apache-tomcat-8.5.12/lib

cp ./apache-tomcat-8.5.14/lib/jsp-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/servlet-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-api.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-coyote.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar 
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/websocket-api.jar 
../apps/apache-tomcat-8.5.12/lib




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: OT: Java Textbook?

[Richard Huntrods]

Completely off-topic.  But I figure this is the perfect group to ask 
this question to.  I will be teaching a university level intro to Java 
programming (for non-programming majors) in the spring semester.  I am 
looking for a good textbook to use.   I've been out of academia for 
years.  So I'm not up to date on available java textbooks.   If you 
are aware of a good textbook, please let me know.  You can reply 
here.  Or just PM me at the address above (please put 'textbook' in 
the subject line if you PM me).


Thanks.

Jerry (ProfJerry.com) 


Jerry,
I do teach intro Java programming at an on-line University, plus I've 
taught Java for many years in other colleges and continuing-ed programs.


My personal preferred text is Bruce Eckel's "Thinking in Java", but it's 
really more of a reference text than a good "reader". There are many 
easy to read texts, but I find them all very short on substance.


Our course currently uses the OER (Online Educational Resource) text 
JavaNotes, a.k.a. "Introduction to Programming Using Java",, 7ed by 
David Eck. I'm not terribly fond of this book.


https://math.hws.edu/javanotes/

I am currently revising the course and will be using the 8th edition of 
the same text by Eck.


https://math.hws.edu/eck/cs124/javanotes8/

The primary benefit of this text is that it is OER. That means it's 
free, and being OER you are free to modifiy/edit/extend the book as long 
as you observe the OER rules, which basically state you keep the 
authorship intact.


Frankly, I think OER is the wave of the future in texts simply because 
it takes the power away from the book publishers and puts it back in the 
hands of those who directly benefit from having free, good texts.


Cheers,
-Richard



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Re: Resource Request - MySQL Data Pool

[Richard Huntrods]

Chris,

Thanks. Lots to go through...

On 3/26/2019 9:00 AM, Christopher Schultz wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Richard,

On 3/25/19 14:15, Richard Huntrods wrote:

 It's time to update my application to use "real" (i.e.
current best practices) data connection pooling.

:)


My application is Java Servlets, no beans, no JSP. Database is
MySQL.

System etc. details: Ubuntu live server 18.04.2, built March 6,
2019.

MySQL - latest installed via 'apt-get install mysql-server' after
system build.

So... MariaDB, then? Or does Ubuntu still stock MySQL binaries?

Seems to be MySQL. See next...



OpenJVM - 11? - again, latest version installed via 'apt-get
install default-jdk' at same time.

Should be pretty easy to determine this:

$ java -version


I typed 'java -version' and this was the output:

openjdk version "10.0.2" 2018-07-17
OpenJDK Runtime Environment (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4)
OpenJDK 64-Bit Server VM (build 10.0.2+13-Ubuntu-1ubuntu0.18.04.4, mixed 
mode)


I also typed 'mysql -version' and got this (still not sure if Ubuntu 
uses MariaDB or MySQL by default):


mysql  Ver 14.14 Distrib 5.7.25, for Linux (x86_64) using EditLine wrapper




Tomcat 8.5.39 - just updated the same day it came out.

Sounds good so far.


This system has been running in production since the early 2001's.
OS has changed over the years from Sun Solaris 8.x to Solaris 10.x
and now to Ubuntu 18.04 (server). Java has been updated over the
years as well, as has Tomcat and MySQL. Through all that the system
works quite perfectly.

Except... there are occasional hangs that implicate the 'home
grown' data connection pool.  I wrote this by hand (in Java) back
in 2001 because there was nothing much available back then. Since
it kept working, I didn't have the time/inclination to change over
the years.

You may find that your home-grown connection pool is actually okay,
but it's being used incorrectly by client code (which is also your
code). IF you have problems with the client code, the "real"
connection-pool can help you tolerate them, but it won't magically fix
them.


I had problems some years ago with one particular version of the 
connector which had a memory leak (in the connector). I avoided that 
version and have had no particular problems. Some years ago I did a 
pretty exhaustive examination of my application using various metering 
tools to see if I was creating memory leaks with my database code. I 
found one (forgot to close the connection), fixed it and there weren't 
any more.


I also encapsulate ALL my database access into a single "DBMS.java" 
class which is used by all the servlets to access data. The DBMS class 
calls the various pool creation and management classes as needed, so all 
my data "stuff" is in one place (or set of classes).


That makes it simple but also makes it more complex as the "roll my own" 
pool is quite integrated into the DBMS code. I'll have to simplify and 
then do the testing as you suggest below.



But the latest connector (mysql-connector-java-8.0.15.jar, a.k.a.
"com.mysql.cj.jdbc.Driver" is giving me some hiccups. I thought
rather than trying to debug my own connection pool, it was time to
switch over to a proper "modern" supported connection pooling
system.

Which brings me to my question.

Would the community please weigh in on the BEST tutorials /
documents regarding creating a Tomcat/MySQL database connection
pool for Servlets (not JSP or beans) with some good code examples
and server.xml examples?

I've already done some extensive internet searches, but when you
are doing something for the first time it's hard to tell the
difference between "really really good" and "blogger who has not
really tried it".

You will want Tomcat to create the connection pool for you. Anything
else is a waste of time. Here's what happens:


Here we are in total agreement. I *want* Tomcat to manage the pool as I 
suspect pool timeouts are the overall issue that I'm seeing. Basically, 
after several hours of inactivity (the application isn't used a lot 
these days), it just "loses" it's connection and then subsequent data 
accesses generate exceptions as the connection is no longer present. It 
does not happen when the system is being used and data accessed 
regularly, only if the system sits idle for several hours.


So at least to me it's clearly an issue with the home-grown connection 
pool "losing" touch with the database but not in a way that is evident 
to my current code. I've resorted to "tricks" using cron and another 
servlet to regularly access the database to keep the pool open, but I 
figured a Tomcat managed pool would have more capability to handle such 
things.


I could rewrite my own pool, but at this point I'd rather use Tomcat 
pools as I can just offload that portion of my code to a community 
resource, which 

Re: Re: Resource Request - MySQL Data Pool

[Richard Huntrods]

Luis,

Thanks very much. I'll have a look.

Cheers,

-Richard

On 3/26/2019 1:43 AM, Luis Rodríguez Fernández wrote:

Hello Richard,

In my experience the best is to "start simple". I would have a look at the
apache tomcat doc [1], configure your pool with a minimal setup and test.
Everything depends on your application workload, how your queries looks
like, etc,  so I am afraid that there are no "silver bullets" in this
domain.

Hope it helps,

Luis


[1]
https://tomcat.apache.org/tomcat-8.5-doc/jndi-datasource-examples-howto.html






El lun., 25 mar. 2019 a las 19:15, Richard Huntrods ()
escribió:


 It's time to update my application to use "real" (i.e. current
best practices) data connection pooling.

My application is Java Servlets, no beans, no JSP. Database is MySQL.

System etc. details:
Ubuntu live server 18.04.2, built March 6, 2019.

MySQL - latest installed via 'apt-get install mysql-server' after system
build.

OpenJVM - 11? - again, latest version installed via 'apt-get install
default-jdk' at same time.

Tomcat 8.5.39 - just updated the same day it came out.

This system has been running in production since the early 2001's. OS
has changed over the years from Sun Solaris 8.x to Solaris 10.x and now
to Ubuntu 18.04 (server). Java has been updated over the years as well,
as has Tomcat and MySQL. Through all that the system works quite perfectly.

Except... there are occasional hangs that implicate the 'home grown'
data connection pool.  I wrote this by hand (in Java) back in 2001
because there was nothing much available back then. Since it kept
working, I didn't have the time/inclination to change over the years.

But the latest connector (mysql-connector-java-8.0.15.jar, a.k.a.
"com.mysql.cj.jdbc.Driver" is giving me some hiccups. I thought rather
than trying to debug my own connection pool, it was time to switch over
to a proper "modern" supported connection pooling system.

Which brings me to my question.

Would the community please weigh in on the BEST tutorials / documents
regarding creating a Tomcat/MySQL database connection pool for Servlets
(not JSP or beans) with some good code examples and server.xml examples?

I've already done some extensive internet searches, but when you are
doing something for the first time it's hard to tell the difference
between "really really good" and "blogger who has not really tried it".

Thanks very much in advance.

-Richard


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


-
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

Resource Request - MySQL Data Pool

[Richard Huntrods]

 It's time to update my application to use "real" (i.e. current 
best practices) data connection pooling.


My application is Java Servlets, no beans, no JSP. Database is MySQL.

System etc. details:
Ubuntu live server 18.04.2, built March 6, 2019.

MySQL - latest installed via 'apt-get install mysql-server' after system 
build.


OpenJVM - 11? - again, latest version installed via 'apt-get install 
default-jdk' at same time.


Tomcat 8.5.39 - just updated the same day it came out.

This system has been running in production since the early 2001's. OS 
has changed over the years from Sun Solaris 8.x to Solaris 10.x and now 
to Ubuntu 18.04 (server). Java has been updated over the years as well, 
as has Tomcat and MySQL. Through all that the system works quite perfectly.


Except... there are occasional hangs that implicate the 'home grown' 
data connection pool.  I wrote this by hand (in Java) back in 2001 
because there was nothing much available back then. Since it kept 
working, I didn't have the time/inclination to change over the years.


But the latest connector (mysql-connector-java-8.0.15.jar, a.k.a. 
"com.mysql.cj.jdbc.Driver" is giving me some hiccups. I thought rather 
than trying to debug my own connection pool, it was time to switch over 
to a proper "modern" supported connection pooling system.


Which brings me to my question.

Would the community please weigh in on the BEST tutorials / documents 
regarding creating a Tomcat/MySQL database connection pool for Servlets 
(not JSP or beans) with some good code examples and server.xml examples?


I've already done some extensive internet searches, but when you are 
doing something for the first time it's hard to tell the difference 
between "really really good" and "blogger who has not really tried it".


Thanks very much in advance.

-Richard


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Problem with SSH in latest Tomcat

[Richard Huntrods]

Greetings!

I would like to 'do what's necessary' to remove the following error. 
Google tells me it's related to my security implementation, which is 
HTTPS by default. I am convinced the problem is in how I invoke the port 
443 connector in my server.xml. I've been running this servlet on 
versions of Tomcat since 2001, and have kept my Tomcat instances up to 
date. Most recently I started noticing this in the logs, and
am pretty sure it's because I've been copying the connector code bit 
from server.xml to server.xml as I upgraded versions of Tomcat.


I really suspect my connector is now out-of-date and could use some 
guideance as to the best new form. I see in the recent server.xml they 
use a different involcation, but don't know if this is best...


OS: Ubuntu 18.04 LTS Live server
Tomcat: 8.5.39, installed from tar.gz obtained from Tomcat.

I've done this enough times to "get it right", so it's just this Hello 
error I want to eradicate...


Here is the error message:

08-Apr-2019 01:00:23.477 SEVERE [https-jsse-nio-443-exec-9] 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun

 java.lang.UnsupportedOperationException: Unsupported SSL v2.0 ClientHello
    at 
java.base/sun.security.ssl.SSLEngineInputRecord.handleUnknownRecord(SSLEngineInputRecord.java:373)
    at 
java.base/sun.security.ssl.SSLEngineInputRecord.decode(SSLEngineInputRecord.java:195)
    at 
java.base/sun.security.ssl.SSLEngineImpl.readRecord(SSLEngineImpl.java:975)
    at 
java.base/sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:902)
    at 
java.base/sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:680)

    at java.base/javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:626)
    at 
org.apache.tomcat.util.net.SecureNioChannel.handshakeUnwrap(SecureNioChannel.java:475)
    at 
org.apache.tomcat.util.net.SecureNioChannel.handshake(SecureNioChannel.java:238)
    at 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1475)
    at 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
    at 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

    at java.base/java.lang.Thread.run(Thread.java:844)

My certificates are new and correct, and have run fine in past versions 
of Tomcat without problems...


THIS IS MY SERVER.XML - Most of it is identical to the server.xml 
supplied with Tomcat 8.5.39 My changes are after the *** THIS IS MY 
CONNECTOR ... *** comment.


Thanks,
-Richard

**




  className="org.apache.catalina.startup.VersionLoggerListener" />

  
  
  

  
  className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
  className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
  className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />


  
  
    
    
  

  
  

    

    


    
    
    

    
    
    
    
    
    
    

       maxThreads="150" enableLookups="false" scheme="https" 
secure="true"

   keystoreFile="./keys/.keystore" keystorePass="password"
   clientAuth="false" sslProtocol="TLS" />

    
    


    

    
    

  
  

  
  
    
    
  

  

    
    

    
    directory="logs"

   prefix="localhost_access_log" suffix=".txt"
   pattern="%h %l %u %t %r %s %b" />

    showReport="false" showServerInfo="false" />


  
    
  



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Is there a problem with the digest?

[Richard Huntrods]

Why google? Actually I was continuing to research the problem I'd 
posted, and the digest archive showed up as the first two hits. :-)


-R

On 4/12/2019 7:34 AM, Konstantin Kolinko wrote:

пт, 12 апр. 2019 г. в 17:27, Richard Huntrods :

It's been four days since I've seen a 'users-dig...@tomcat.apache.org'
email. I posted a question on April 9, and no digest since (I subscribed
to the digest), yet I found a reply on the digest archive by searching
with Google.

Why Google? The are several public archives of this mailing list, as
listed here:
https://tomcat.apache.org/lists.html#tomcat-users


So again... is there a problem with digest emails? I have no spam
filters enabled and there's nothing in a junk or trash folder.

I also tried sending a blank email to
users-digest-h...@tomcat.apache.org yesterday and no reply from that either.

I never tried sending a "blank" email. Those may be rejected by spam
filer (as well as e-mails using HTML formatting).

I usually add a few lines of text.

Best regards,
Konstantin Kolinko



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Is there a problem with the digest?

[Richard Huntrods]

It's been four days since I've seen a 'users-dig...@tomcat.apache.org' 
email. I posted a question on April 9, and no digest since (I subscribed 
to the digest), yet I found a reply on the digest archive by searching 
with Google.


So again... is there a problem with digest emails? I have no spam 
filters enabled and there's nothing in a junk or trash folder.


I also tried sending a blank email to 
users-digest-h...@tomcat.apache.org yesterday and no reply from that either.


-R


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Is there a problem with the digest?

[Richard Huntrods]

Nothing changed since before your server crashed to after, and I've 
checked all junk and spam filters.


I am still not receiving any of the digests anymore. Are the digests 
even being sent out?


Thanks,

-R


On 12/04/2019 16:32, Mark Thomas wrote:
> On 12/04/2019 16:29, Mark Thomas wrote:
>> Which address did you use to subscribe to the digest list? It wasn't
>> this one...
> 
> Ignore that. ezmlm cmd line error on my part. I see your digest

> subscription in the logs from this address. Hmmm.
> 
> Let me go and dig into the mail logs...


Nothing obvious. And my test digest subscription is working. Are you
still having issues?

Mark

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




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Connector difference explanation request - two ways of getting SSL in server.xml

[Richard Huntrods]

Apologies if this is really basic, but I've seen two ways of handling
https (SSL) for tomcat and don't understand the differences.

The first example uses letsencrypt cert files 'in situ' (i.e. where they
have been created). The second example uses the same files, but
converted by a manual shell script into a single .keystore file, stored
in ./tomcat/keys

The thing I really don't understand is the different protocols used.

Fair warning: the second example is something I've been using for a
while, so it may be out of fashion even though it works. The first
example is "brand new" that I got online and want to use mainly because
it removes the manual conversion step from cert to .keystore.


   
 
   


vs.



My system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 8.5.41 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16

Everything works fine. I'm mostly just curious about the other
differences between the two connectors.

Thanks in advance.


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: Is there a problem with the digest?

[Richard Huntrods]

ROkdh
  ZmMZtFlsQeQJsWoqGrQo/kEYicVlMVOgjmOOzOa5fRb/IqlGlBn4a4me3hWthLLtMy+OOEim
  6ENjntVTBQiTP/YqrxWDbCkaD7b2e9wY5N3JlRxMIQHfcHaND3PRdQSn7oHYXmJl
Message-ID: 
Date: Thu, 18 Apr 2019 12:12:23 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
  Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Language: en-GB
Content-Transfer-Encoding: 7bit

On 17/04/2019 19:28, Richard Huntrods wrote:
> Nothing changed since before your server crashed to after, and I've
> checked all junk and spam filters.
> 
> I am still not receiving any of the digests anymore. Are the digests

> even being sent out?

Yes they are. Looking in the logs I see a bunch of deliveries to your
mail host shortly after you sent this message. Did any of those arrive
in your inbox? If so, the headers may be instructive.

Mark


> 
> Thanks,
> 
> -R
> 
>> On 12/04/2019 16:32, Mark Thomas wrote:

>> > On 12/04/2019 16:29, Mark Thomas wrote:
>> >> Which address did you use to subscribe to the digest list? It wasn't
>> >> this one...
>> > > Ignore that. ezmlm cmd line error on my part. I see your digest
>> > subscription in the logs from this address. Hmmm.
>> > > Let me go and dig into the mail logs...
>>
>> Nothing obvious. And my test digest subscription is working. Are you
>> still having issues?
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> 
> 
> 
> ---

> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 



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

Re: [NUCLEUS #813966] Urgent: Problem receiving email

[Richard Huntrods]

there are two email addresses that send the emails to me.

Tomcat Users List 

and Tomcat Digest 

I used to get only the digest, but this week even emails from 'users' 
are not coming through at all.


Cheers,

-Richard

On 4/18/2019 5:42 PM, Nigel Koppert via RT wrote:

Hi Richard,

Unfortunately there's not much we can tell from the message you 
provided for examination, as it appears all of sender/receiver 
information is only referencing the apache server that is hosting 
their mail accounts; there are no references to huntr...@nucleus.com.
Could you please provide us with the mail address that sends these 
digests to huntr...@nucleus.com? Once I have that information I can 
put an inquiry in with our mail admins.
  


--
Nigel Koppert
Support Analyst
Nucleus Information Service

Phone: (403) 509-4960
Toll Free: (888) 466-6336

On 2019-04-18 19:59:21, huntr...@nucleus.com wrote:

Greetings!

Could you please look at the mail server that supports the above email
address (huntr...@nucleus.com)?

Last week I stopped receiving emails from the tomcat forum. They had a
server outage and changed servers, and ever since I have not received a
single email from the list or the digest.

I've been able to send emails to them, and received word (via the digest
archive using a browser) that they have been sending me emails as
recently as yesterday.

Attached is an email from yesterday that I did not receive. I've
obtained it from the archive in 'raw' form so you can inspect the
headers and try and find out why I am not receiving these emails.

I should also note I've checked the spam, junk and other folders on this
email account and there is nothing there.

Thanks,

-Richard




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: Cannot receive email from tomcat.apache.org

[Richard Huntrods]

I'm still not receiving any email from either 'users@tomcat.apache.org' 
or 'users-dig...@tomcat.apache.org' - not since the tomcat listserv 
server crash in early April.


I asked my mail server provider to check their logs, and this is the 
reply I received yesterday:



Hello Richard,

I received a response from our email admin team this morning regarding 
your inquiry:

There were no emails sent from users@tomcat.apache.org or
users-dig...@tomcat.apache.org to our system between April 15 and 
April 18th.
There was an email sent from huntr...@nucleus.com to 
users@tomcat.apache.org on

Apr 17 14:28:59 EST.

You may want to inquire with the people distributing this digest if 
they can send you a test message to determine what might be causing 
the non-delivery issue, as we are not even seeing it coming into our 
server at this time. 


This seems odd as I know I saw messages on the archive from that time - 
so I should have received at least the digest.


Since my provider is of little help, I have two questions for the 
tomcat.apache.org mailing list admins:


1. Is the digest still being emailed on a regular basis? I never was 
subscribed to 'users', only to 'users-digest'.


2. Could you check and see whether or not tomcat.apache.org has 
"blacklisted" the server 'nucleus.com'? This happened to me once before 
- a site blacklisted nucleus "because it looked suspicious". Nucleus.com 
is a Calgary Alberta Canada internet provider that has been in business 
since before 2000 (I've been a customer since early 2001) and is most 
certainly not 'suspicious'. They host many of the larger Calgary 
business accounts as well as consumer accounts. Their email servers are 
robust and secure.


But - it could be the listserv my not recognize nucleus.com and 
therefore won't email to it.


3. Is there any way to reply directly to me at this email address from a 
'tomcat.apache.org' mail address so we could test this?


Thanks,

-Richard


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Cannot receive email from tomcat.apache.org

[Richard Huntrods]

I have confirmed with my email provider that tomcat.apache.org does 
indeed have nucleus.com on a blacklist. I can provide proof if needed, 
but I do need to get nucleus.com REMOVED from this blacklist.


Thank you.

-Richard

On 4/23/2019 9:14 AM, Richard Huntrods wrote:
I'm still not receiving any email from either 
'users@tomcat.apache.org' or 'users-dig...@tomcat.apache.org' - not 
since the tomcat listserv server crash in early April.


I asked my mail server provider to check their logs, and this is the 
reply I received yesterday:



Hello Richard,

I received a response from our email admin team this morning 
regarding your inquiry:

There were no emails sent from users@tomcat.apache.org or
users-dig...@tomcat.apache.org to our system between April 15 and 
April 18th.
There was an email sent from huntr...@nucleus.com to 
users@tomcat.apache.org on

Apr 17 14:28:59 EST.

You may want to inquire with the people distributing this digest if 
they can send you a test message to determine what might be causing 
the non-delivery issue, as we are not even seeing it coming into our 
server at this time. 


This seems odd as I know I saw messages on the archive from that time 
- so I should have received at least the digest.


Since my provider is of little help, I have two questions for the 
tomcat.apache.org mailing list admins:


1. Is the digest still being emailed on a regular basis? I never was 
subscribed to 'users', only to 'users-digest'.


2. Could you check and see whether or not tomcat.apache.org has 
"blacklisted" the server 'nucleus.com'? This happened to me once 
before - a site blacklisted nucleus "because it looked suspicious". 
Nucleus.com is a Calgary Alberta Canada internet provider that has 
been in business since before 2000 (I've been a customer since early 
2001) and is most certainly not 'suspicious'. They host many of the 
larger Calgary business accounts as well as consumer accounts. Their 
email servers are robust and secure.


But - it could be the listserv my not recognize nucleus.com and 
therefore won't email to it.


3. Is there any way to reply directly to me at this email address from 
a 'tomcat.apache.org' mail address so we could test this?


Thanks,

-Richard



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: Re: Database timeout

[Richard Huntrods]

On 7/27/2019 7:18 AM, Mark Thomas wrote:
> On 26/07/2019 02:44, Richard Huntrods wrote:
>> I'm having an ongoing issue with the database connections timing out
>> after a long period of inactivity (i.e. no-one connecting to the tomcat
>> applicaton).
>>
>> But first...
>>
>> My system:
>> OS: Ubuntu 18.04.2 LTS (server)
>> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
>> Java: OpenJDK "11.0.3" 2019-04-16
>> Mysql: Ver 14.14 Distrib 5.7.26
>>
>> I'm using the standard 8-hour timeout on mysql connections, and have the
>> set autoReconnect=true when I connect to the database:
>>
>> jdbc:mysql://127.0.0.1:3306/mydb?autoReconnect=true
> Full configuration please.

The database is run entirely from within the servlets and supporting
Java code, no configuration at all in server.xml. Unfortunately it's a
legacy part of the system that I have not had the time to rewrite.

Basically the only change to the default server.xml is to add the 443
enabling block and point it to our certificates. I don't change anything
else from what is supplied as the standard tomcat 9.0.22 tar.gz file
aside from clearing out the default webapps directory.

I'll see what I can grab in the way of database configuration from the code.

>
> Mark
>
>
>> Everything works fine except for the 8-hour timeouts. If I click the
>> tomcat link again, the autoReconnect works and the applications is back
>> up instantly.
>>
>> The only message in any log is this:
>>
>>> SQL Problem: The last packet successfully received from the server was 
>>> 30,394,076 milliseconds ago.  The last packet sent successfully to the 
>>> server was 30,394,076 milliseconds ago. is longer than the server 
>>> configured value of 'wait_timeout'. You should consider either expiring 
>>> and/or testing connection validity before use in your application, 
>>> increasing the server configured values for client timeouts, or using the 
>>> Connector/J connection property 'autoReconnect=true' to avoid this problem.
>>> SQL State: 08S01
>>> Vendor Error: 0
>> Is there a way other than using a longer timeout value to stop the
>> connection from breaking? That is, is there a pre-emptive form of
>> autoReconnect?
>>
>> Some other statistics: I have a 'watchdog' process (servlet + cron job)
>> that exercises the database on regular intervals. In spite of that, I
>> still get these SQL timeouts.
>>
>> I've been tracking the timeouts since April 2019. All timeouts exceed 8
>> hours. The minimum between timeouts was 9.3 hours, maximum  was 166.1
>> hours with an average since April 2019 of 35 hours.
>>
>> Thanks in advance.
>>
>> -Richard
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> --
>> This communication is intended for the use of the recipient to whom it is 
>> addressed, and may contain confidential, personal, and or privileged 
>> information. Please contact us immediately if you are not the intended 
>> recipient of this communication, and do not copy, distribute, or take action 
>> relying on it. Any communications received in error, or subsequent reply, 
>> should be deleted or destroyed.
>> ---
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: Re: Database timeout

[Richard Huntrods]

On 7/27/2019 9:43 PM, Christopher Schultz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Richard,
>
> On 7/25/19 21:44, Richard Huntrods wrote:
>> I'm having an ongoing issue with the database connections timing
>> out after a long period of inactivity (i.e. no-one connecting to
>> the tomcat applicaton).
>>
>> But first...
>>
>> My system: OS: Ubuntu 18.04.2 LTS (server) Tomcat: 9.0.22
>> (installed from tomcat distribution, not via apt get) Java: OpenJDK
>> "11.0.3" 2019-04-16 Mysql: Ver 14.14 Distrib 5.7.26
>>
>> I'm using the standard 8-hour timeout on mysql connections, and
>> have the set autoReconnect=true when I connect to the database:
>>
>> jdbc:mysql://127.0.0.1:3306/mydb?autoReconnect=true
>>
>> Everything works fine except for the 8-hour timeouts. If I click
>> the tomcat link again, the autoReconnect works and the applications
>> is back up instantly.
> This is the documented behavior of MySQL Connector/J: after a
> disconnect, it will fail the first subsequent connection usage and
> mark the connection as failed. Only after that will the connection
> become available the reconnect.
Yes, that is what I understand from reading the documents. I was just
hoping there might be another config item I missed.
>
>> The only message in any log is this:
>>
>>> SQL Problem: The last packet successfully received from the
>>> server was 30,394,076 milliseconds ago.  The last packet sent
>>> successfully to the server was 30,394,076 milliseconds ago. is
>>> longer than the server configured value of 'wait_timeout'. You
>>> should consider either expiring and/or testing connection
>>> validity before use in your application, increasing the server
>>> configured values for client timeouts, or using the Connector/J
>>> connection property 'autoReconnect=true' to avoid this problem.
>>> SQL State: 08S01 Vendor Error: 0
>> Is there a way other than using a longer timeout value to stop the
>> connection from breaking? That is, is there a pre-emptive form of
>> autoReconnect?
> You should be using a connection pool with a connection
> validation-check. If you enable those, you shouldn't even have the
> "SQL Problem" after a timeout.

 we do use a Java coded connection pool that's legacy code that I
have not had a chance to replace. It does work, except for the timeout.

The timeout itself is not unexpected. The client took a big hit in the
economic downturn and there is almost no activity on the application,
sometimes for weeks at a time.  Basically, with no-one using the system
it's behaving as one would expect.

It's just that when you do go to log on, it *always* seems to be down,
do to lack of activity. Click refresh and it's back up (again, as
expected). I'd just like to have it not go down.

>> Some other statistics: I have a 'watchdog' process (servlet + cron
>> job) that exercises the database on regular intervals. In spite of
>> that, I still get these SQL timeouts.
> Maybe it's not doing what you think it is.

Again, I suspect this is the case. I have no idea why that should be,
but when you remove all that's obvious, what is left must be suspected.

Looks like I will be digging into / rebuilding this code.

>
>> I've been tracking the timeouts since April 2019. All timeouts
>> exceed 8 hours. The minimum between timeouts was 9.3 hours, maximum
>> was 166.1 hours with an average since April 2019 of 35 hours.
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09J/IACgkQHPApP6U8
> pFjjqA//ULfwUhS4r0NWVxIljVck9uUHKtzJW5Wk2fzCnjr0MQh3h4bNJSZj7Myt
> aFUWt3Cw+KmJ1zSOoAkDpDIvfvJsszCJhE5NP7DGi7iZMcA9Ln4JIpVEFpIbOj+J
> 9dV9+yHom60vLefwhl8v+Rh5PYsA6Sr87T6PXj8wkIrPvdr5LGnz+YzONFaCZKok
> R9YujGVoDiA3mI+FXX3V6BwyOw2w7zwJYJHRJ6kdB/bVjzcZ0DDsW1OOo5iifAeX
> IevbR7pa+K0GuCZrvzje/6MefI3Lm6giXFReMIU4PpwLL+oITM6ImbYuUJxA7Lqk
> kWb79SQAcw5MAlbeNXVuYL/1eGuyG1Vf5wkAZj4sf8XPMWeyWbstLOk6WN7Mwtm3
> 0ALPQgSs1Dhb8BUVOgCC4AtfvbBfE3/47dP6ZDumU8DNfV78SZdKcaaWvFSXobZu
> m0qk8raDdAhRxQ8FwJlzgZLWU7sqTjxw9D8F5mD9VPiTxD/IuVxGV9fOZDKN9vP4
> q69km58evlFew0KIkHQE7MCKhDL7+oQ9Q7i3/dJmxHXxwWLpZDLTAGWANes/ksD6
> GAsWkpFHejNu/cNJYOJ/B2Yl1FvPPqq1k0QBVQTYleJ+FXThOzJOyShd38tMdWgW
> bcy7ZeUgglI6B1VNlxp7ROQhA3fj5xOexL/sqi5kWICNiAsaQwU=
> =0TT3
> -END PGP SIGNATURE-
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contac

Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

Fixed it by brute force.

First, I tried putting the changes ONLY in
../tomcat/webapps/ROOT/WEB-INF/web.xml instead of ../tomcat/conf/web.xml

The good news is that didn't affect the servlet application. The bad
news is now the http://mydomain.com/ started getting the 404 error. So I
undid that and the error went away.

That led me to the brute force approach.

The application (servlets on tomcat) has a large set of static web pages
that are used as promotional material for the application. In the early
days this was on a different apache server, but over the years (and due
to colocation costs) migrated to the ROOT directory of tomcat. It's
always worked just fine, so why mess with stuff that's working and not
'wrong'.

There are about a dozen html pages and lots of other files, but only the
dozen html pages matter. They all have a single link (via tabbed menu)
to "index.html". It was not difficult to rename index.html to be
home.html and change all the links (took all of 10 min total). I then
created a new index.html with the single key line in :

 https://mydomain.com/home.html;>

This line I've used before in other java servlet/tomcat applications
when I really want http://mydomain.com to automatically redirect to the
servlet application (I change home.html to the servlet URL). It works.

After making this change - and I didn't even have to restart tomcat - it
now works perfectly.

Eventually I'll figure out what I did wrong trying to use web.xml to do
the above auto-redirection, but this works and is simple.

-R

On 7/20/2019 7:47 AM, Richard Huntrods wrote:
> OK. That was really weird.
>
> As I said in my message, following the directions on the web did NOT
> work. It didn't force redirection from http to https.
>
> What it DID end up doing was to kill the tomcat servlet application.
> Before the change it was working fine, and after the change it would
> only generate a 404 page.
>
> I reverted to the original /conf/web.xml, restarted tomcat and the
> servlet application is back up and running perfectly.
>
> So this code in /conf/web.xml affected the servlet but not the ROOT
> static web pages.
>
> I'm thinking I need to make the change I noted, but in ROOT/web.xml
> instead. I'll try that today. But it was weird that the change in
> /conf/web.xml killed the servlet but didn't affect the ROOT static
> pages at all. Especially weird  since the servlet application ONLY
> runs on port 443 (https).
>
> -R
>
> On 7/19/2019 7:18 PM, Richard Huntrods wrote:
>> I tried implementing automatic redirection from HTTP to HTTPS on my
>> tomcat today, but it's not working.
>>
>> First, my system:
>> OS: Ubuntu 18.04.2 LTS (server)
>> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
>> Java: OpenJDK "11.0.3" 2019-04-16
>> Mysql: Ver 14.14 Distrib 5.7.26
>>
>> This web application has it's own domain (let's call it
>> "mydomain.com" ) and has working HTTPS - and has done  for some time
>> now.
>>
>> Static web pages are served on this application via tomcat using the
>> ROOT directory ../tomcat/webapps/ROOT
>>
>> Again, this is working just fine. If I type "https://mydomain.com; I
>> see the secure static pages. If I type "http://mydomain.com; I see
>> the same pages, but browsers inform me the page isn't secure.
>>
>> I want to force tomcat to redirect "http://mydomain.com; to
>> "https://mydomain.com; always.
>>
>> I found instructions for auto-redirection on several on-line sites,
>> and all had the same instructions.
>>
>> I already have the redirect code in server.xml:
>>
>>   >connectionTimeout="2"
>>redirectPort="443" />
>>
>> So all I had to add (according to the instructions) was code at the
>> end of ...tomcat/conf/web.xml
>>
>> 
>> 
>> Secured
>> /*
>> 
>> 
>> CONFIDENTIAL
>> 
>> 
>>
>> just before the final 
>>
>> I did this and restarted tomcat. It doesn't work.
>>
>> After restarting tomcat, if I type in "http://mydomain.com; I still
>> see the unsecured version. It does not auto-redirect to https.
>>
>> What am I missing?
>>
>> Thanks,
>> -Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

Thanks. However, what I don't understand is why putting that code into the 
webapps WEB-INF/web.xml would cause the behaviour I want in ROOT.

Sadly, this is a production server and I can't play with it except after hours.

EDIT. I tried working with web.xml on my development server, and could not get 
it to work, no matter which web.xml I used. In fact, whenever I edited the 
'correct' web.xml, I immediately started getting '404' errors. If I removed the 
changes and restarted, the errors went away.

So I tried something different after re-checking the internet. My original info 
came from here:
https://gist.github.com/jtgasper3/10501274

after typing "force tomcat http to https" the above link was one, and the one 
I'd used to originally edit tomcat/conf/web.xml.

The following bit caught my eye:
albertus82 commented on Oct 31, 2018
Some applications don't work correctly with that security-constraint, so I 
followed a completely different approach:
Edit conf/server.xml and add the following element into :

Create the file conf/Catalina/localhost/rewrite.config:
RewriteCond %{HTTPS} =off
RewriteRule ^(.*) https://%{HTTP_HOST}:443$1 [R=301]

I tried that on localhost (devel box) and it didn't work at first, but only 
because I did not have port 80 'turned on' on that machine. Once I did that it 
worked.

I then implemented the above 'fix' in the production conf/server.xml and 
conf/Catalina/localhost and after restarting tomcat, ALL PAGES redirect from  
http to https as I had wanted. I even put the web pages back to just using 
index.html (moral: always make backups before you start doing stuff!).

On reflection, I do think the valve was the more appropriate way to tackle this 
problem, so I'm very happy with the solution.

-R

On 7/20/2019 3:48 AM, logo wrote:

Richard,



Am 20.07.2019 um 04:19 schrieb Richard Huntrods 
<mailto:huntr...@athabascau.ca>:

I tried implementing automatic redirection from HTTP to HTTPS on my
tomcat today, but it's not working.

First, my system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26

This web application has it's own domain (let's call it "mydomain.com" )
and has working HTTPS - and has done  for some time now.

Static web pages are served on this application via tomcat using the
ROOT directory ../tomcat/webapps/ROOT

Again, this is working just fine. If I type 
"https://mydomain.com;<https://mydomain.com> I see
the secure static pages. If I type "http://mydomain.com;<http://mydomain.com> I 
see the same
pages, but browsers inform me the page isn't secure.

I want to force tomcat to redirect "http://mydomain.com;<http://mydomain.com> to
"https://mydomain.com;<https://mydomain.com> always.

I found instructions for auto-redirection on several on-line sites, and
all had the same instructions.

I already have the redirect code in server.xml:

  

So all I had to add (according to the instructions) was code at the end
of ...tomcat/conf/web.xml



Secured
/*


CONFIDENTIAL



just before the final 


This should go into your webapp's WEB-INF/web.xml! Not the tomcat/conf!

Hope this helps,

Peter



I did this and restarted tomcat. It doesn't work.

After restarting tomcat, if I type in 
"http://mydomain.com;<http://mydomain.com> I still see
the unsecured version. It does not auto-redirect to https.

What am I missing?

Thanks,
-Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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



[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
  Virus-free. 
www.avast.com<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recip

Re: Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

Sorry for top-posting. It's the default with my mail program
(thunderbird)...

On 7/20/2019 11:27 AM, Konstantin Kolinko wrote:
> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods :
>> OK. That was really weird.
>>
>> As I said in my message, following the directions on the web did NOT
>> work. It didn't force redirection from http to https.
>>
>> What it DID end up doing was to kill the tomcat servlet application.
>> Before the change it was working fine, and after the change it would
>> only generate a 404 page.
>>
>> I reverted to the original /conf/web.xml, restarted tomcat and the
>> servlet application is back up and running perfectly.
>>
>> So this code in /conf/web.xml affected the servlet but not the ROOT
>> static web pages.
> 1. The web.xml file and its behavior are defined in the Servlet Specification.
>
> Some random instructions on the net have to be used carefully.
>
> 2. The web.xml file is the one in your web application (WEB-INF/web.xml).
>
> The /conf/web.xml file provides defaults for all web applications, and
> SHOULD not be edited. (The /conf/context.xml should not be exited as
> well. That is another frequent error.).
>
> Those defaults are merged with the web.xml file of your web
> application using merging rules defined in the Servlet Specification.
>
> There is an option, "logEffectiveWebXml" [1] that turns on logging of
> the merged web.xml file.
I still am having trouble understanding why the web application's
WEB-INF/web.xml would be the appropriate place to put the change when I
want to affect ROOT. I would have thought webapps/ROOT/WEB-INF/web.xml
would have been the correct one.
>
> 3. Beware of typos.
>
> The tag "" is misspelled.

AARRR

TYPOS

And I checked that code several times before implementing it. Of course
it wouldn't work 'as designed'. Ouch.

I can clearly see why 'fixing stuff' using that code would generate the
404 errors I was seeing. That does prove I was editing the correct
web.xml files, at least. Since the typo was in the block that then
defined the url-pattern, messing that up would mess up everything.

One person asked what the logs said. Nothing. Start up log was normal,
access log was normal.

>
> There is an option, "xmlValidation" [1] that turns on automatic
> validation of web.xml against the XML schema specified in that file.
>
> (Personally, I usually run with
> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
> and that turns "xmlValidation" on as well).
>
> 4. Top-posting is bad.

Again, sorry. In the end I solved it using a Rewritevalve instead of
web.xml, and I think that may be the more elegant solution. Certainly
it's cleaner - edit server.xml and add one file, rewrite.config. That
takes care of everywhere; both the static pages I started wanting to
fix, and also the servlet application which I discovered could be forced
to run http when I was testing. This fixes all.

One last point. I started this particular application for a client back
in early 2001. At that time I was considered a maverick for choosing
open source (Tomcat, MySQL) over the then-ubiquitous proprietary
solutions "everyone" was using. I even got to speak at Unix user groups
at the time, and even spoke at a CIPS meeting in August 2001 (Montreal,
PQ, Canada) on the use of open source for enterprise solutions.

Mostly folks simply didn't want to believe it could be done.

Fast forward to 2019, when Tomcat & Mysql/MariaDB are now often the
ubiquitous choices, with proprietary solutions are used mostly where
upper management has bought the FUD.

A lot has changed in Tomcat in that time; in Unix as well. I started
with Solaris 8, then Solaris 10, and more recently Ubuntu. I love the
way things have gotten better.

More than that, I try to "keep up" with changes in security and overall
robustness and best practices. I did just update from Tomcat 8.5.41 to
9.0.22 on Wednesday. It went without a hitch and took about 30 minutes
total, including testing on the devel server. Basically it was easy
because I try and keep things up to date.

But... there are still places where legacy code lives in the
application. Sadly, I'm one developer and it was a pretty big system. I
tend to be proactive, but only if I think the benefit can really justify
the time spent figuring it all out.

Cheers,

-Richard

> [1] http://tomcat.apache.org/tomcat-9.0-doc/config/context.html
>
> Best regards,
> Konstantin Kolinko
>

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
infor

Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

OK. That was really weird.

As I said in my message, following the directions on the web did NOT
work. It didn't force redirection from http to https.

What it DID end up doing was to kill the tomcat servlet application.
Before the change it was working fine, and after the change it would
only generate a 404 page.

I reverted to the original /conf/web.xml, restarted tomcat and the
servlet application is back up and running perfectly.

So this code in /conf/web.xml affected the servlet but not the ROOT
static web pages.

I'm thinking I need to make the change I noted, but in ROOT/web.xml
instead. I'll try that today. But it was weird that the change in
/conf/web.xml killed the servlet but didn't affect the ROOT static pages
at all. Especially weird  since the servlet application ONLY runs on
port 443 (https).

-R

On 7/19/2019 7:18 PM, Richard Huntrods wrote:
> I tried implementing automatic redirection from HTTP to HTTPS on my
> tomcat today, but it's not working.
>
> First, my system:
> OS: Ubuntu 18.04.2 LTS (server)
> Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
> Java: OpenJDK "11.0.3" 2019-04-16
> Mysql: Ver 14.14 Distrib 5.7.26
>
> This web application has it's own domain (let's call it "mydomain.com"
> ) and has working HTTPS - and has done  for some time now.
>
> Static web pages are served on this application via tomcat using the
> ROOT directory ../tomcat/webapps/ROOT
>
> Again, this is working just fine. If I type "https://mydomain.com; I
> see the secure static pages. If I type "http://mydomain.com; I see the
> same pages, but browsers inform me the page isn't secure.
>
> I want to force tomcat to redirect "http://mydomain.com; to
> "https://mydomain.com; always.
>
> I found instructions for auto-redirection on several on-line sites,
> and all had the same instructions.
>
> I already have the redirect code in server.xml:
>
>   connectionTimeout="2"
>redirectPort="443" />
>
> So all I had to add (according to the instructions) was code at the
> end of ...tomcat/conf/web.xml
>
> 
> 
> Secured
> /*
> 
> 
> CONFIDENTIAL
> 
> 
>
> just before the final 
>
> I did this and restarted tomcat. It doesn't work.
>
> After restarting tomcat, if I type in "http://mydomain.com; I still
> see the unsecured version. It does not auto-redirect to https.
>
> What am I missing?
>
> Thanks,
> -Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: HTTP to HTTPS redirect not happening

[Richard Huntrods]

I apologise for top posting in advance, but just a quick update and
quicker question...

After Konstantin found my typo, I tried editing the global web.xml file
(/conf/web.xml) . In my case, this is actually the file I want based on
the behaviour described by Konstantin as this entire tomcat instance is
for this one application and it's static web pages, so *everything*
needs to have the redirect.

After fixing the typo, I tried it again and it works perfectly.

So now I have two ways to accomplish what I want:
1. Edit /conf/web.xml and add the lines.

2. Edit server.xml and add the RewriteValve line, then create
rewrite.config in /conf/Catalina/localhost.

So my question - which is considered "more elegant" or better, more
appropriate appoach - the valve or the change to web.xml?

I'm leaning towards the valve simply because I kind of like the whole
concept of valves, but if editing web.xml is just as good... ?

Thanks,

-Richard


On 7/20/2019 2:08 PM, Richard Huntrods wrote:
> Sorry for top-posting. It's the default with my mail program
> (thunderbird)...
>
> On 7/20/2019 11:27 AM, Konstantin Kolinko wrote:
>> сб, 20 июл. 2019 г. в 17:47, Richard Huntrods :
>>> OK. That was really weird.
>>>
>>> As I said in my message, following the directions on the web did NOT
>>> work. It didn't force redirection from http to https.
>>>
>>> What it DID end up doing was to kill the tomcat servlet application.
>>> Before the change it was working fine, and after the change it would
>>> only generate a 404 page.
>>>
>>> I reverted to the original /conf/web.xml, restarted tomcat and the
>>> servlet application is back up and running perfectly.
>>>
>>> So this code in /conf/web.xml affected the servlet but not the ROOT
>>> static web pages.
>> 1. The web.xml file and its behavior are defined in the Servlet
>> Specification.
>>
>> Some random instructions on the net have to be used carefully.
>>
>> 2. The web.xml file is the one in your web application
>> (WEB-INF/web.xml).
>>
>> The /conf/web.xml file provides defaults for all web applications, and
>> SHOULD not be edited. (The /conf/context.xml should not be exited as
>> well. That is another frequent error.).
>>
>> Those defaults are merged with the web.xml file of your web
>> application using merging rules defined in the Servlet Specification.
>>
>> There is an option, "logEffectiveWebXml" [1] that turns on logging of
>> the merged web.xml file.
> I still am having trouble understanding why the web application's
> WEB-INF/web.xml would be the appropriate place to put the change when
> I want to affect ROOT. I would have thought
> webapps/ROOT/WEB-INF/web.xml would have been the correct one.
>>
>> 3. Beware of typos.
>>
>> The tag "" is misspelled.
>
> AARRR
>
> TYPOS
>
> And I checked that code several times before implementing it. Of
> course it wouldn't work 'as designed'. Ouch.
>
> I can clearly see why 'fixing stuff' using that code would generate
> the 404 errors I was seeing. That does prove I was editing the correct
> web.xml files, at least. Since the typo was in the block that then
> defined the url-pattern, messing that up would mess up everything.
>
> One person asked what the logs said. Nothing. Start up log was normal,
> access log was normal.
>
>>
>> There is an option, "xmlValidation" [1] that turns on automatic
>> validation of web.xml against the XML schema specified in that file.
>>
>> (Personally, I usually run with
>> org.apache.catalina.STRICT_SERVLET_COMPLIANCE=true
>> and that turns "xmlValidation" on as well).
>>
>> 4. Top-posting is bad.
>
> Again, sorry. In the end I solved it using a Rewritevalve instead of
> web.xml, and I think that may be the more elegant solution. Certainly
> it's cleaner - edit server.xml and add one file, rewrite.config. That
> takes care of everywhere; both the static pages I started wanting to
> fix, and also the servlet application which I discovered could be
> forced to run http when I was testing. This fixes all.
>
> One last point. I started this particular application for a client
> back in early 2001. At that time I was considered a maverick for
> choosing open source (Tomcat, MySQL) over the then-ubiquitous
> proprietary solutions "everyone" was using. I even got to speak at
> Unix user groups at the time, and even spoke at a CIPS meeting in
> August 2001 (Montreal, PQ, Canada) on the use of open source for
> enterprise solutions.
>
> Mostly folks simply didn't want to believe it could be done.
>
> Fa

HTTP to HTTPS redirect not happening

[Richard Huntrods]

I tried implementing automatic redirection from HTTP to HTTPS on my
tomcat today, but it's not working.

First, my system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26

This web application has it's own domain (let's call it "mydomain.com" )
and has working HTTPS - and has done  for some time now.

Static web pages are served on this application via tomcat using the
ROOT directory ../tomcat/webapps/ROOT

Again, this is working just fine. If I type "https://mydomain.com; I see
the secure static pages. If I type "http://mydomain.com; I see the same
pages, but browsers inform me the page isn't secure.

I want to force tomcat to redirect "http://mydomain.com; to
"https://mydomain.com; always.

I found instructions for auto-redirection on several on-line sites, and
all had the same instructions.

I already have the redirect code in server.xml:

   

So all I had to add (according to the instructions) was code at the end
of ...tomcat/conf/web.xml

 
 
 Secured
 /*
 
 
 CONFIDENTIAL
 
 

just before the final 

I did this and restarted tomcat. It doesn't work.

After restarting tomcat, if I type in "http://mydomain.com; I still see
the unsecured version. It does not auto-redirect to https.

What am I missing?

Thanks,
-Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Database timeout

[Richard Huntrods]

I'm having an ongoing issue with the database connections timing out
after a long period of inactivity (i.e. no-one connecting to the tomcat
applicaton).

But first...

My system:
OS: Ubuntu 18.04.2 LTS (server)
Tomcat: 9.0.22 (installed from tomcat distribution, not via apt get)
Java: OpenJDK "11.0.3" 2019-04-16
Mysql: Ver 14.14 Distrib 5.7.26

I'm using the standard 8-hour timeout on mysql connections, and have the
set autoReconnect=true when I connect to the database:

jdbc:mysql://127.0.0.1:3306/mydb?autoReconnect=true

Everything works fine except for the 8-hour timeouts. If I click the
tomcat link again, the autoReconnect works and the applications is back
up instantly.

The only message in any log is this:

> SQL Problem: The last packet successfully received from the server was 
> 30,394,076 milliseconds ago.  The last packet sent successfully to the server 
> was 30,394,076 milliseconds ago. is longer than the server configured value 
> of 'wait_timeout'. You should consider either expiring and/or testing 
> connection validity before use in your application, increasing the server 
> configured values for client timeouts, or using the Connector/J connection 
> property 'autoReconnect=true' to avoid this problem.
> SQL State: 08S01
> Vendor Error: 0

Is there a way other than using a longer timeout value to stop the
connection from breaking? That is, is there a pre-emptive form of
autoReconnect?

Some other statistics: I have a 'watchdog' process (servlet + cron job)
that exercises the database on regular intervals. In spite of that, I
still get these SQL timeouts.

I've been tracking the timeouts since April 2019. All timeouts exceed 8
hours. The minimum between timeouts was 9.3 hours, maximum  was 166.1
hours with an average since April 2019 of 35 hours.

Thanks in advance.

-Richard

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: Re: Proposal: Note on web site that Tomcat 10 is a milestone-release

[Richard Huntrods]

On 3/4/2020 6:28 AM, Martin Grigorov wrote:

On Wed, Mar 4, 2020 at 4:02 PM Johan Compagner 
wrote:




Or for now generate 2 build artifacts? (as long as it is really just

the

package rename)


Hm, no. I just tested locally Tomcat 10.0.1 with Apache Wicket (9.x,
master). Nothing more.
Tomcat 10.0.x is not production ready so it is too early to do anything
about Jakarta APIs in Wicket.
First we need to release Wicket 9.0.0 (with Javax APIs) and then we can
start thinking about Jakarta APIs.



yes exactly, so many frameworks are going to do that (wait)
So not release any artifacts that use the new jakarta api's
So that means that for many people they can't start test or use Tomcat 10..
Because who is using plain servlet api only?
Any 3rd part dependency is your code  that uses some javax.servlet package
needs to make a special release..
This will take ages, not to mention will only be really done for the latest
releases of those packages (like Wicket 9)


There is no official release of Jakarta EE 9 yet!
I didn't even bother to replace javax.servlet:servlet-api Maven dependency
with the Jakarta one in Wicket.
I just used https://github.com/apache/tomcat-jakartaee-migration to migrate
(already built) wicket-examples.war and it worked fine!
Later I tried to do the same with a Spring Boot based application but the
migration tool faced some problems with the nested archives in Boot's
special packaging.

Tomcat 10.0.x is for early adopters to test it and report issues. But as
Chris suggested we should make this more clear in the docs!
I've committed some improvements. If anyone have more ideas for improvement
I'll be happy to apply them! :-)


Thank you for that Martin. I installed 10.0.x today, and as expected it
broke because all my servlets are based on javax. I grabbed a copy of
the migration tool. Sadly (for me) it required Maven to build, but after
some hesitency, I grabbed Maven and installed that (it was really easy).

With Maven installed and working, I built the migration tool. Again,
easy. With the tool built I simply converted both of my application's
war files, copied them over the originals in webapps, started TC 10 and
everything worked!

So I guess I'm "ready" for TC10 now. :-)

-R


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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

Re: users Digest 22 Jun 2020 10:06:54 -0000 Issue 13885

[Richard Huntrods]

Brian & Calder,

On 6/22/2020 3:06 AM, 
users-digest-h...@tomcat.apache.org 
wrote:

On Mon, Jun 22, 2020, 01:04 Brian 
 wrote

[ snip ]

- For some reason, the people at Ubuntu/Debian/Linux decided that Tomcat's


log should be found inside syslog, instead of staying independent inside
"catalina.out". Why is that? I don't know and I don't like it!


[ snip ]
.
Sorry - don't have a specific answer for your Ubuntu implementation.
.
However, this is one reason we do not use "distro-specific" Tomcat
installations (to include implementations of WebSphere and WebLogic).
.
For example, we grab the plain vanilla Tomcat ZIP and extract it to "/opt/"
(as in "/opt/tomcat/") - we now have complete control over its
configuration and runtime instantiation.

I agree completely. I started with Tomcat in 2000 on Sun Sparc servers running 
Solaris 8. Over the years I gradually updated to Solaris 10 on Sparc then Intel 
servers. Finally a couple of years ago I switched to Ubuntu (currently 
18.04LTS) for simplicity in engaging the community.

Because my development server was a windows/intel machine (now perma-set to 
Win7) I needed a generic way to operate Tomcat on any OS.

As mentioned above, I always grabbed the zip and/or the tar.gz and simply 
extracted the file to an appropriate working directory. For Ubuntu, I use 
/opt/tomcat as well. This allows me to keep things under my control, or at 
least know where everything is and that it will remain relatively constant. Any 
variations or changes are well documented in the Tomcat changelogs and 
assistance can be rendered by the community.

Likewise I try and keep my Tomcat current and my Java versions consistent with 
the current Tomcat. I've found that although the upgrade process can sometimes 
be painful, it is at least well documented.

Cheers,

-Richard




[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
  Virus-free. 
www.avast.com
--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

Re: ClassFileTransformer in Tomcat 10 common classloader

[Richard Huntrods]

On 28.12.21 00:36, Chew Kok Hoor wrote:


We're using the old javax.servlet namespace for compatibility reasons.

 Some of our jar files are re-used by different web-apps, therefore we
placed them in the common classloader.

 Is it possible to convert them dynamically, just like how we do it for
servlets in the per app WEB-INF folder, by using the following in the
context file:




I have a similar situation. I run two sites on different servers. Today
I upgraded to TC 9.0.56 on both without incident. (I do the upgrades
manually from the tar.gz files).

However, in keeping up with where things are going, I also run a
development copy of the latest 10 (currently 10.0.14). Initially I ran
the offline converter, but as my main applications are still running in
production under 9.0.x, I don't really want to convert them from
javax.servlet to jakarta.servlet just yet.

My overall deployments are quite simple. I don't modify much on a stock
download of tomcat - just server.xml (to add HTTPS support for my certs)
and web.xml (to force HTTPS). Maybe 10 lines different in both files.

My libraries for the applications are now stored in webapps rather than
the common library area, but ALL my stuff still run javax.servlet.

I found that by adding the single line "  " after the  in the main
conf/context.xml file, everything auto-converts and runs perfectly.

Frankly, for my purposes, this has to be the simplest solution.

Cheers,

-R


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
This communication is intended for the use of the recipient to whom it is 
addressed, and may contain confidential, personal, and or privileged 
information. Please contact us immediately if you are not the intended 
recipient of this communication, and do not copy, distribute, or take action 
relying on it. Any communications received in error, or subsequent reply, 
should be deleted or destroyed.
---

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