Re: Tomcat 9 returning 404 for audio files

[Sam]

Hi Chris,

I'm creating the audio file dynamically from DB and  I check if the file
exists using File.exists() method.

Before returning the html code with audio tag, I'm verifying that file
exists on File System.

Thanks!

On Mon, Mar 11, 2024 at 2:36 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Sam,
>
> On 3/11/24 13:04, Sam wrote:
> > On the server side, I'm checking that file exists before returning the
> file
> > path to the browser. We are also dynamically creating pdf files this way
> > and no issues with accessing them.
>
> How are you checking to see if the file exists? It's possible that your
> check-for-existance triggers the "not found" in Tomcat's 
> instance, then you create your file on-disk and return the path to the
> browser, then the browser requests the path and gets the cached "not
> found".
>
> > I found something interesting:
> > https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
> > link:
> > *Resources are cached by default.*
> >
> > I'll try with *Cache-Control* request header and see if it helps!
>
> This isn't likey to be the problem. I think the cache you are fighting
> is the one Tomcat maintains for "resources" which is how Tomcat loads
> things from ... well, everywhere. Not caching things like "not found"
> makes things go very slowly.
>
> -chris
>
> > On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:
> >
> >> On 11/03/2024 11:31, Sam wrote:
> >>> Thanks for replying!!
> >>>
> >>> Yes audio files are generated dynamically from DB.in a Servlet.
> >>>
> >>> I've verified that audio file exists on file system before returning
> the
> >>> html code that contains audo control.
> >>
> >> Is there any chance of an attempt to access the file before it is
> >> created? The resources implementation can cache "not found" results for
> >> a short period of time.
> >>
> >> You might want to test the code with a simple text file to determine
> >> whether file type is a factor (which seems unlikely but you never know).
> >>
> >> Mark
> >>
> >>>
> >>>
> >>> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
> >>>
>  On 11/03/2024 02:21, Sam wrote:
> > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > deployed as a war file. I'm facing a weird issue with audio files
>  playback.
> >
> > When loading a page that contains an audio file. First time Tomcat
>  returns
> > 404 error but if reloading the page, audio file is loaded properly
> and
> >> no
> > error from Tomcat.
> >
> > I'm using html 5 audio control to display the file.
> >
> > All other static resources(images, css and js files) are working
> >> without
> > any issues. Only audio files are having this issue.
> >
> > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
>  entry
> > when I try to open the audio file first time. I can see 404 being
>  returned
> > from server in Chrome dev tools.
> >
> >
> > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> >> and
> > data*
> > Following is the log for 2nd attempt. This time audio is available
> and
> > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > DefaultServlet.serveResource: Serving resource
> > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data
> *
> > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > contentType='audio/mpeg'*
> 
>  Are the audio files generated dynamically on request?
> 
>  Mark
> 
> 
> >
> > Here is the audio control code:
> >
> > 
> >>>
> >   >>>
> > >> src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> > type="audio/mpeg" >
> >  
> >   
> > 
> > I've tried relative path and full path but result is the same in both
>  cases.
> >
> > I've spent days trying to solve this but no luck :(
> >
> > I would really appreciate any guidance to solve this issue.
> >
> > Thanks!
> >
> 
>  -
>  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: When does Tomcat add and remove threads?

[John.E.Gregg]

Chris,


From: Christopher Schultz 
Sent: Monday, March 11, 2024 5:09 PM
To: users@tomcat.apache.org 
Subject: Re: When does Tomcat add and remove threads?

John,

On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:
> I am using Tomcat 9.x.
>
> When does Tomcat add and remove threads from its internal thread
> pool?  I'm talking about the threads with names like
> http-nio-8080-exec-1.  It appears the thread pool is Tomcat's own
> ThreadPoolExecutor but I don't see the exact behavior documented.
> I'm familiar with how java.util.concurrent does it, but it looks like
> Tomcat's version is a little different.
Are you looking for a technical explanation with code references, or a
plain-English description of when threads are created and added?

-chris

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


Mostly plain English like the j.u.c. ThreadPoolExecutor Java doc has.  What 
happens when all core threads are in use?  When do tasks go on the queue?  When 
does core thread + 1 get added?  When do threads get removed?

Thanks

Re: When does Tomcat add and remove threads?

[Christopher Schultz]

John,

On 3/11/24 17:47, john.e.gr...@wellsfargo.com.INVALID wrote:

I am using Tomcat 9.x.

When does Tomcat add and remove threads from its internal thread
pool?  I'm talking about the threads with names like
http-nio-8080-exec-1.  It appears the thread pool is Tomcat's own
ThreadPoolExecutor but I don't see the exact behavior documented.
I'm familiar with how java.util.concurrent does it, but it looks like
Tomcat's version is a little different.
Are you looking for a technical explanation with code references, or a 
plain-English description of when threads are created and added?


-chris

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

Re: how to reload SSL certificates without restarting Tomcat

[Christopher Schultz]

Jerry,

On 3/11/24 14:51, Jerry Lin wrote:

Hi Chris,

There is also this:

https://tomcat.apache.org/presentations.html#latest-lets-encrypt

It's very LE-focused, but it shows you how to programmatically trigger a
reload.



Thanks for your presentation and script. We are using Let's Encrypt, so
your material is quite relevant.


If I were to present that material today, it would be a lot shorter. In 
fact, I was asked last-minute to fill-in for a missing speaker in 
Halifax and I updated that presentation a bit and made it more of a 
conversation with the audience.


I hadn't included anything about the automatic-update feature Tomcat has 
added since the previous staging of that presentation and afterwards I 
went in and removed something like 40% of the material in the presentation.


So it's all perfectly valid, but it's even easier to use LE with Tomcat, 
now.


-chris

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

When does Tomcat add and remove threads?

[John.E.Gregg]

I am using Tomcat 9.x.

When does Tomcat add and remove threads from its internal thread pool?  I'm 
talking about the threads with names like http-nio-8080-exec-1.  It appears the 
thread pool is Tomcat's own ThreadPoolExecutor but I don't see the exact 
behavior documented.  I'm familiar with how java.util.concurrent does it, but 
it looks like Tomcat's version is a little different.

Thanks

Re: how to reload SSL certificates without restarting Tomcat

[Jerry Lin]

Hi Chris,

There is also this:
> https://tomcat.apache.org/presentations.html#latest-lets-encrypt
>
> It's very LE-focused, but it shows you how to programmatically trigger a
> reload.
>

Thanks for your presentation and script. We are using Let's Encrypt, so
your material is quite relevant.

Jerry

Re: Tomcat 9 returning 404 for audio files

[Christopher Schultz]

Sam,

On 3/11/24 13:04, Sam wrote:

On the server side, I'm checking that file exists before returning the file
path to the browser. We are also dynamically creating pdf files this way
and no issues with accessing them.


How are you checking to see if the file exists? It's possible that your 
check-for-existance triggers the "not found" in Tomcat's  
instance, then you create your file on-disk and return the path to the 
browser, then the browser requests the path and gets the cached "not found".



I found something interesting:
https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
link:
*Resources are cached by default.*

I'll try with *Cache-Control* request header and see if it helps!


This isn't likey to be the problem. I think the cache you are fighting 
is the one Tomcat maintains for "resources" which is how Tomcat loads 
things from ... well, everywhere. Not caching things like "not found" 
makes things go very slowly.


-chris


On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:


On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is
created? The resources implementation can cache "not found" results for
a short period of time.

You might want to test the code with a simple text file to determine
whether file type is a factor (which seems unlikely but you never know).

Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns

404 error but if reloading the page, audio file is loaded properly and

no

error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working

without

any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers

and

data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


  
bottom:0;"



 


   
src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"

type="audio/mpeg" >
 
  

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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: [OT] Tomcat SMPT TLS1.2

[Brandie Nickey]

Update!  The fix was indeed to replace the out of date java mail jar (1.5) with 
the newest Jakarta mail jar file.  Thanks everyone for the help!

Brandie

-Original Message-
From: Christopher Schultz  
Sent: Monday, March 11, 2024 11:29 AM
To: users@tomcat.apache.org
Subject: Re: [OT] Tomcat SMPT TLS1.2

[You don't often get email from ch...@christopherschultz.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

Brandie,

(Marking this [OT] as it's not really a Tomcat question.)

On 3/11/24 12:34, Brandie Nickey wrote:
> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have 
> been trying to find out where to configure outbound smtp messages to 
> use only TLS1.2.  I've found plenty of info on the https using TLS1.2 
> and have configured that just fine in server.xml file and in the Java 
> tab of the tomcatw.exe file, but that doesn't seem to be applying to
> the emails outgoing from the webapp.   Anyone have any ideas? (Also
> upgrading is not an option as this tomcat/java combo is the only one 
> supported by the vendor for our webapp version).

Assuming that you are using JavaMail for your email, I assembled a whole lot of 
properties that can be fed to JavaMail when making SMTP connections and 
documented them here:

https://github.com/ChristopherSchultz/java-email/blob/main/src/main/resources/mail.properties

It's been a very long time since I looked at that code, but if you look at the 
code for Mailer.java in that project, you should be able to see how the 
properties are used to establish a Transport (aka connection) and Session.

Most of the properties are passed-through to 
Session.getDefaultInstance(Properties).

-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: [OT] Tomcat SMPT TLS1.2

[Christopher Schultz]

Brandie,

(Marking this [OT] as it's not really a Tomcat question.)

On 3/11/24 12:34, Brandie Nickey wrote:

I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have
been trying to find out where to configure outbound smtp messages to
use only TLS1.2.  I've found plenty of info on the https using TLS1.2
and have configured that just fine in server.xml file and in the Java
tab of the tomcatw.exe file, but that doesn't seem to be applying to
the emails outgoing from the webapp.   Anyone have any ideas? (Also
upgrading is not an option as this tomcat/java combo is the only one
supported by the vendor for our webapp version).


Assuming that you are using JavaMail for your email, I assembled a whole
lot of properties that can be fed to JavaMail when making SMTP
connections and documented them here:

https://github.com/ChristopherSchultz/java-email/blob/main/src/main/resources/mail.properties

It's been a very long time since I looked at that code, but if you look 
at the code for Mailer.java in that project, you should be able to see 
how the properties are used to establish a Transport (aka connection) 
and Session.


Most of the properties are passed-through to 
Session.getDefaultInstance(Properties).


-chris

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

Re: how to reload SSL certificates without restarting Tomcat

[Christopher Schultz]

Jerry,

On 3/10/24 16:00, Jerry Lin wrote:

Hi Chuck,

Presumably, you mean “not behind https", since “Apache” refers to the

organization that develops and maintains a plethora of software products.



Yes, “not behind https" (I meant not behind an Apache HTTP server)



you can configure the TLS config listener:


https://tomcat.apache.org/tomcat-10.1-doc/config/listeners.html#TLS_configuration_reload_listener_-_org.apache.catalina.security.TLSCertificateReloadListener



Great, thanks! This is what I was looking for.


There is also this:
https://tomcat.apache.org/presentations.html#latest-lets-encrypt

It's very LE-focused, but it shows you how to programmatically trigger a 
reload.


Chuck's reference to the auto-reloading is even better if you don't mind 
the background process checking for you, instead of 
proactively-triggering the reload.


-chris

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

Re: reloading context with manager-script

[Christopher Schultz]

Mark,

On 3/10/24 08:49, Mark Thomas wrote:

On 10/03/2024 10:50, Greg Huber wrote:

Hello,

Using http://tomcat/manager-app/text/reload?path=/

When I reload an application (in java), I get a reply

OK - Reloaded application at context path [/]

but when the application is not present I get this reply:

FAIL - No context exists named []

Is it intentional that the fail shows the ascii code rather than the 
slash like on the OK?


Yes.

If the provided context exists then we know that the name is HTML safe 
since all valid context names are HTML safe. In this case there is no 
escaping.


If the context does not exist then the provided content name may not be 
HTML safe (it could be a deliberate XSS attempt) hence it is escaped.


What is the Content-Type of the response? The URL implies that it's a 
text interface, not HTML.


-chris

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

Re: Tomcat 9 returning 404 for audio files

[Sam]

Service is running on Windows, I've verified no access issues!

Issue occurs only the first time, Subsequently audio loads properly.

Thank you!

On Mon, Mar 11, 2024 at 12:43 PM Ivano Luberti 
wrote:

> Could it be the file is created with incorrect access rights?
>
> Il 11/03/2024 16:46, Mark Thomas ha scritto:
> > On 11/03/2024 11:31, Sam wrote:
> >> Thanks for replying!!
> >>
> >> Yes audio files are generated dynamically from DB.in a Servlet.
> >>
> >> I've verified that audio file exists on file system before returning the
> >> html code that contains audo control.
> >
> > Is there any chance of an attempt to access the file before it is
> > created? The resources implementation can cache "not found" results
> > for a short period of time.
> >
> > You might want to test the code with a simple text file to determine
> > whether file type is a factor (which seems unlikely but you never know).
> >
> > Mark
> >
> >>
> >>
> >> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
> >>
> >>> On 11/03/2024 02:21, Sam wrote:
>  I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
>  deployed as a war file. I'm facing a weird issue with audio files
> >>> playback.
> 
>  When loading a page that contains an audio file. First time Tomcat
> >>> returns
>  404 error but if reloading the page, audio file is loaded properly
>  and no
>  error from Tomcat.
> 
>  I'm using html 5 audio control to display the file.
> 
>  All other static resources(images, css and js files) are working
>  without
>  any issues. Only audio files are having this issue.
> 
>  I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> >>> entry
>  when I try to open the audio file first time. I can see 404 being
> >>> returned
>  from server in Chrome dev tools.
> 
> 
>  *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
>  resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3'
>  headers and
>  data*
>  Following is the log for 2nd attempt. This time audio is available and
>  playable in browser. *09-Mar-2024 20:13:00.371 INFO
>  DefaultServlet.serveResource: Serving resource
>  '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
>  *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
>  contentType='audio/mpeg'*
> >>>
> >>> Are the audio files generated dynamically on request?
> >>>
> >>> Mark
> >>>
> >>>
> 
>  Here is the audio control code:
> 
>  
>    >
>  
>  src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
>  type="audio/mpeg" >
>  
>   
>  
>  I've tried relative path and full path but result is the same in both
> >>> cases.
> 
>  I've spent days trying to solve this but no luck :(
> 
>  I would really appreciate any guidance to solve this issue.
> 
>  Thanks!
> 
> >>>
> >>> -
> >>> 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
> >
> --
>
> Archimede Informatica tratta i dati personali in conformità a quanto
> stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
> 2003 n. 196
> per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
> Informativa completa
> <
> http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf
> >
>
> Il contenuto di questo messaggio e dei suoi eventuali allegati è
> riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di
> contattare telefonicamente o via e-mail il mittente ai recapiti sopra
> indicati e di cancellare il messaggio e gli eventuali allegati dal Suo
> sistema senza farne copia o diffonderli. Le opinioni espresse sono
> quelle dell'autore e non rappresentano necessariamente quelle della
> Società.
> This message and any attachment are confidential.If you are not the
> intended recipient, please telephone or email the sender and delete this
> message and any attachment from your system. If you are not the intended
> recipient you must not copy this message or attachment or disclose the
> contents to any other person. Any opinions presented are solely those of
> the author and do not necessarily represent those of the Company.
>
> dott. Ivano Mario Luberti
>
> Archimede Informatica società cooperativa a r. l.
> Via Gereschi 36, 56127 Pisa
>
> tel.: +39 050/580959 | fax: +39 050/8932061
>
> web: www.archicoop.it
> linkedin: www.linkedin.com/in/ivanoluberti
> facebook: www.facebook.com/archimedeinformaticapisa/
>

Re: Tomcat 9 returning 404 for audio files

[Sam]

On the server side, I'm checking that file exists before returning the file
path to the browser. We are also dynamically creating pdf files this way
and no issues with accessing them.

I found something interesting:
https://tomcat.apache.org/tomcat-9.0-doc/config/resources.html From this
link:
*Resources are cached by default.*

I'll try with *Cache-Control* request header and see if it helps!

Thank you!

On Mon, Mar 11, 2024 at 11:46 AM Mark Thomas  wrote:

> On 11/03/2024 11:31, Sam wrote:
> > Thanks for replying!!
> >
> > Yes audio files are generated dynamically from DB.in a Servlet.
> >
> > I've verified that audio file exists on file system before returning the
> > html code that contains audo control.
>
> Is there any chance of an attempt to access the file before it is
> created? The resources implementation can cache "not found" results for
> a short period of time.
>
> You might want to test the code with a simple text file to determine
> whether file type is a factor (which seems unlikely but you never know).
>
> Mark
>
> >
> >
> > On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
> >
> >> On 11/03/2024 02:21, Sam wrote:
> >>> I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> >>> deployed as a war file. I'm facing a weird issue with audio files
> >> playback.
> >>>
> >>> When loading a page that contains an audio file. First time Tomcat
> >> returns
> >>> 404 error but if reloading the page, audio file is loaded properly and
> no
> >>> error from Tomcat.
> >>>
> >>> I'm using html 5 audio control to display the file.
> >>>
> >>> All other static resources(images, css and js files) are working
> without
> >>> any issues. Only audio files are having this issue.
> >>>
> >>> I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> >> entry
> >>> when I try to open the audio file first time. I can see 404 being
> >> returned
> >>> from server in Chrome dev tools.
> >>>
> >>>
> >>> *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> >>> resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> and
> >>> data*
> >>> Following is the log for 2nd attempt. This time audio is available and
> >>> playable in browser. *09-Mar-2024 20:13:00.371 INFO
> >>> DefaultServlet.serveResource: Serving resource
> >>> '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> >>> *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> >>> contentType='audio/mpeg'*
> >>
> >> Are the audio files generated dynamically on request?
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Here is the audio control code:
> >>>
> >>> 
> >>>   
> >>>  >
> >>>src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> >>> type="audio/mpeg" >
> >>> 
> >>>  
> >>> 
> >>> I've tried relative path and full path but result is the same in both
> >> cases.
> >>>
> >>> I've spent days trying to solve this but no luck :(
> >>>
> >>> I would really appreciate any guidance to solve this issue.
> >>>
> >>> Thanks!
> >>>
> >>
> >> -
> >> 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 SMPT TLS1.2

[Robert Turner]

You can define Java properties in one of the Tomcat files
(catalina.properties I believe), albeit it may depend on the OS /
deployment for your specific instance as some use different loaders -- the
default scripts "catalina.sh/bat" will use that file, but
some distributions load Tomcat differently.

On Mon, Mar 11, 2024 at 12:50 PM Brandie Nickey
 wrote:

> That makes sense,  I did see a file in our java mail jar called
> SocketFetcher that has a line to the extent saying 'if properties not set,
> use TLS 1.0 for smtp' .  My hope was to find where the heck to set the mail
> properties, but sounds like that's in another sun file.
>
> -Original Message-
> From: Ivano Luberti 
> Sent: Monday, March 11, 2024 9:46 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat SMPT TLS1.2
>
> [You don't often get email from lube...@archicoop.it.invalid. Learn why
> this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> I had issues in the past connectin to mailserver using TLS and solved them
> upgrading the webapplicatio library from mail-1.4.jar to
> javax.mail-1.6.2.jar
>
> Il 11/03/2024 17:41, Robert Turner ha scritto:
> > AFAIK, there is nothing in Tomcat for SMTP. This would be part of the
> > application you are running typically. It's possible (but not
> > guaranteed) that the web application is using the standard Java
> > libraries for SMTP, and as such, you may (but again not guaranteed) be
> > able to configure some of the mail settings via Java system properties
> > (
> > https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-s
> > ummary.html
> > ).
> >
> > Best bet is to work with your application provider and their
> > documentation / support.
> >
> > Also, consider upgrading Java and Tomcat to current / supported
> > versions as those versions are both very old and likely have many
> > security issues that need patching.
> >
> >
> >
> > On Mon, Mar 11, 2024 at 12:39 PM Jost
> > Richstein
> > wrote:
> >
> >> Hi,
> >>
> >> this is definitely not a Tomcat problem - take a look at:
> >>
> >>
> >> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-
> >> summary
> >> .html
> >>  >> -summary.html>
> >>
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: Brandie Nickey
> >> Gesendet: Montag, 11. März 2024 17:35 An:users@tomcat.apache.org
> >> Betreff: Tomcat SMPT TLS1.2
> >>
> >> Hi all,
> >>
> >> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have
> >> been trying to find out where to configure outbound smtp messages to
> >> use only TLS1.2.  I've found plenty of info on the https using TLS1.2
> >> and have configured that just fine in server.xml file and in the Java
> >> tab of the tomcatw.exe file, but that doesn't seem to be applying to
> the emails
> >> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is
> not
> >> an
> >> option as this tomcat/java combo is the only one supported by the
> >> vendor for our webapp version).
> >>
> >> Thank you!
> >> Brandie
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail:users-h...@tomcat.apache.org
> >>
> >>
> --
>
> Archimede Informatica tratta i dati personali in conformità a quanto
> stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
> 2003 n. 196
> per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
> Informativa completa
> <
> http://www.archicoop.it/fileadmin/pdf/InformativaTrattamentoDatiPersonali.pdf
> >
>
> Il contenuto di questo messaggio e dei suoi eventuali allegati è
> riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di
> contattare telefonicamente o via e-mail il mittente ai recapiti sopra
> indicati e di cancellare il messaggio e gli eventuali allegati dal Suo
> sistema senza farne copia o diffonderli. Le opinioni espresse sono quelle
> dell'autore e non rappresentano necessariamente quelle della Società.
> This message and any attachment are confidential.If you are not the
> intended recipient, please telephone or email the sender and delete this
> message and any attachment from your system. If you are not the intended
> recipient you must not copy this message or attachment or disclose the
> contents to any other person. Any opinions presented are solely those of
> the author and do not necessarily represent those of the Company.
>
> dott. Ivano Mario Luberti
>
> Archimede Informatica società cooperativa a r. l.
> Via Gereschi 36, 56127 Pisa
>
> tel.: +39 050/580959 | fax: +39 050/8932061
>
> web: www.archicoop.it
> linkedin: www.linkedin.com/in/ivanoluberti
> facebook: www.facebook.com/archimedeinformaticapisa/
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: AW: Tomcat SMPT TLS1.2

[Ivano Luberti]

LOL

but to be honest we encountered the issue after moving from JDK 1.7 to 
JDK 1.8 without changing the  SMTP server


Il 11/03/2024 17:49, Jost Richstein ha scritto:

Yes, of course. Mail-1.4.jar is from May 2006. I'm not even sure if TLS existed 
back then.


-Ursprüngliche Nachricht-
Von: Ivano Luberti  
Gesendet: Montag, 11. März 2024 17:46

An:users@tomcat.apache.org
Betreff: Re: Tomcat SMPT TLS1.2

I had issues in the past connectin to mailserver using TLS and solved them 
upgrading the webapplicatio library from mail-1.4.jar to javax.mail-1.6.2.jar

Il 11/03/2024 17:41, Robert Turner ha scritto:

AFAIK, there is nothing in Tomcat for SMTP. This would be part of the
application you are running typically. It's possible (but not
guaranteed) that the web application is using the standard Java
libraries for SMTP, and as such, you may (but again not guaranteed) be
able to configure some of the mail settings via Java system properties
(
https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-s
ummary.html
).

Best bet is to work with your application provider and their
documentation / support.

Also, consider upgrading Java and Tomcat to current / supported
versions as those versions are both very old and likely have many
security issues that need patching.



On Mon, Mar 11, 2024 at 12:39 PM Jost
Richstein
wrote:


Hi,

this is definitely not a Tomcat problem - take a look at:


https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-
summary
.html




-Ursprüngliche Nachricht-
Von: Brandie Nickey
Gesendet: Montag, 11. März 2024 17:35An:users@tomcat.apache.org
Betreff: Tomcat SMPT TLS1.2

Hi all,

I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have
been trying to find out where to configure outbound smtp messages to
use only TLS1.2.  I've found plenty of info on the https using TLS1.2
and have configured that just fine in server.xml file and in the Java
tab of the tomcatw.exe file, but that doesn't seem to be applying to the emails
outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
an
option as this tomcat/java combo is the only one supported by the
vendor for our webapp version).

Thank you!
Brandie



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



--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



Il contenuto di questo messaggio e dei suoi eventuali allegati è 
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di 
contattare telefonicamente o via e-mail il mittente ai recapiti sopra 
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo 
sistema senza farne copia o diffonderli. Le opinioni espresse sono 
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the 
intended recipient, please telephone or email the sender and delete this 
message and any attachment from your system. If you are not the intended 
recipient you must not copy this message or attachment or disclose the 
contents to any other person. Any opinions presented are solely those of 
the author and do not necessarily represent those of the Company.


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

AW: Tomcat SMPT TLS1.2

[Jost Richstein]

Yes, of course. Mail-1.4.jar is from May 2006. I'm not even sure if TLS existed 
back then.


-Ursprüngliche Nachricht-
Von: Ivano Luberti  
Gesendet: Montag, 11. März 2024 17:46
An: users@tomcat.apache.org
Betreff: Re: Tomcat SMPT TLS1.2

I had issues in the past connectin to mailserver using TLS and solved them 
upgrading the webapplicatio library from mail-1.4.jar to javax.mail-1.6.2.jar

Il 11/03/2024 17:41, Robert Turner ha scritto:
> AFAIK, there is nothing in Tomcat for SMTP. This would be part of the 
> application you are running typically. It's possible (but not 
> guaranteed) that the web application is using the standard Java 
> libraries for SMTP, and as such, you may (but again not guaranteed) be 
> able to configure some of the mail settings via Java system properties 
> ( 
> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-s
> ummary.html
> ).
>
> Best bet is to work with your application provider and their 
> documentation / support.
>
> Also, consider upgrading Java and Tomcat to current / supported 
> versions as those versions are both very old and likely have many 
> security issues that need patching.
>
>
>
> On Mon, Mar 11, 2024 at 12:39 PM Jost 
> Richstein
> wrote:
>
>> Hi,
>>
>> this is definitely not a Tomcat problem - take a look at:
>>
>>
>> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-
>> summary
>> .html
>> > -summary.html>
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Brandie Nickey
>> Gesendet: Montag, 11. März 2024 17:35 An:users@tomcat.apache.org
>> Betreff: Tomcat SMPT TLS1.2
>>
>> Hi all,
>>
>> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have 
>> been trying to find out where to configure outbound smtp messages to 
>> use only TLS1.2.  I've found plenty of info on the https using TLS1.2 
>> and have configured that just fine in server.xml file and in the Java 
>> tab of the tomcatw.exe file, but that doesn't seem to be applying to the 
>> emails
>> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
>> an
>> option as this tomcat/java combo is the only one supported by the 
>> vendor for our webapp version).
>>
>> Thank you!
>> Brandie
>>
>>
>>
>> -
>> To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail:users-h...@tomcat.apache.org
>>
>>
-- 

Archimede Informatica tratta i dati personali in conformità a quanto stabilito 
dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
2003 n. 196
per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa


Il contenuto di questo messaggio e dei suoi eventuali allegati è riservato. Nel 
caso in cui Lei non sia il destinatario, La preghiamo di contattare 
telefonicamente o via e-mail il mittente ai recapiti sopra indicati e di 
cancellare il messaggio e gli eventuali allegati dal Suo sistema senza farne 
copia o diffonderli. Le opinioni espresse sono quelle dell'autore e non 
rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the intended 
recipient, please telephone or email the sender and delete this message and any 
attachment from your system. If you are not the intended recipient you must not 
copy this message or attachment or disclose the contents to any other person. 
Any opinions presented are solely those of the author and do not necessarily 
represent those of the Company.

dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/



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

RE: Tomcat SMPT TLS1.2

[Brandie Nickey]

That makes sense,  I did see a file in our java mail jar called SocketFetcher 
that has a line to the extent saying 'if properties not set, use TLS 1.0 for 
smtp' .  My hope was to find where the heck to set the mail properties, but 
sounds like that's in another sun file.  

-Original Message-
From: Ivano Luberti  
Sent: Monday, March 11, 2024 9:46 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat SMPT TLS1.2

[You don't often get email from lube...@archicoop.it.invalid. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

I had issues in the past connectin to mailserver using TLS and solved them 
upgrading the webapplicatio library from mail-1.4.jar to javax.mail-1.6.2.jar

Il 11/03/2024 17:41, Robert Turner ha scritto:
> AFAIK, there is nothing in Tomcat for SMTP. This would be part of the 
> application you are running typically. It's possible (but not 
> guaranteed) that the web application is using the standard Java 
> libraries for SMTP, and as such, you may (but again not guaranteed) be 
> able to configure some of the mail settings via Java system properties 
> ( 
> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-s
> ummary.html
> ).
>
> Best bet is to work with your application provider and their 
> documentation / support.
>
> Also, consider upgrading Java and Tomcat to current / supported 
> versions as those versions are both very old and likely have many 
> security issues that need patching.
>
>
>
> On Mon, Mar 11, 2024 at 12:39 PM Jost 
> Richstein
> wrote:
>
>> Hi,
>>
>> this is definitely not a Tomcat problem - take a look at:
>>
>>
>> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-
>> summary
>> .html
>> > -summary.html>
>>
>>
>> -Ursprüngliche Nachricht-
>> Von: Brandie Nickey
>> Gesendet: Montag, 11. März 2024 17:35 An:users@tomcat.apache.org
>> Betreff: Tomcat SMPT TLS1.2
>>
>> Hi all,
>>
>> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have 
>> been trying to find out where to configure outbound smtp messages to 
>> use only TLS1.2.  I've found plenty of info on the https using TLS1.2 
>> and have configured that just fine in server.xml file and in the Java 
>> tab of the tomcatw.exe file, but that doesn't seem to be applying to the 
>> emails
>> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
>> an
>> option as this tomcat/java combo is the only one supported by the 
>> vendor for our webapp version).
>>
>> Thank you!
>> Brandie
>>
>>
>>
>> -
>> To unsubscribe, e-mail:users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail:users-h...@tomcat.apache.org
>>
>>
--

Archimede Informatica tratta i dati personali in conformità a quanto stabilito 
dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno
2003 n. 196
per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa


Il contenuto di questo messaggio e dei suoi eventuali allegati è riservato. Nel 
caso in cui Lei non sia il destinatario, La preghiamo di contattare 
telefonicamente o via e-mail il mittente ai recapiti sopra indicati e di 
cancellare il messaggio e gli eventuali allegati dal Suo sistema senza farne 
copia o diffonderli. Le opinioni espresse sono quelle dell'autore e non 
rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the intended 
recipient, please telephone or email the sender and delete this message and any 
attachment from your system. If you are not the intended recipient you must not 
copy this message or attachment or disclose the contents to any other person. 
Any opinions presented are solely those of the author and do not necessarily 
represent those of the Company.

dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

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

RE: Tomcat SMPT TLS1.2

[Brandie Nickey]

Thanks so much for the guidance.  Have a call with the vendor in about an hour 
to discuss - my fear is that the TLS 1.0 was hard coded somewhere but will take 
the info provided and see what they say.  Cheers! 

-Original Message-
From: Robert Turner  
Sent: Monday, March 11, 2024 9:42 AM
To: Tomcat Users List 
Subject: Re: Tomcat SMPT TLS1.2

[You don't often get email from rtur...@e-djuster.ca.invalid. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

AFAIK, there is nothing in Tomcat for SMTP. This would be part of the 
application you are running typically. It's possible (but not guaranteed) that 
the web application is using the standard Java libraries for SMTP, and as such, 
you may (but again not guaranteed) be able to configure some of the mail 
settings via Java system properties ( 
https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html
).

Best bet is to work with your application provider and their documentation / 
support.

Also, consider upgrading Java and Tomcat to current / supported versions as 
those versions are both very old and likely have many security issues that need 
patching.



On Mon, Mar 11, 2024 at 12:39 PM Jost Richstein 
wrote:

> Hi,
>
> this is definitely not a Tomcat problem - take a look at:
>
>
> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-s
> ummary
> .html
>  summary.html>
>
>
> -Ursprüngliche Nachricht-
> Von: Brandie Nickey 
> Gesendet: Montag, 11. März 2024 17:35
> An: users@tomcat.apache.org
> Betreff: Tomcat SMPT TLS1.2
>
> Hi all,
>
> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have 
> been trying to find out where to configure outbound smtp messages to 
> use only TLS1.2.  I've found plenty of info on the https using TLS1.2 
> and have configured that just fine in server.xml file and in the Java 
> tab of the tomcatw.exe file, but that doesn't seem to be applying to the 
> emails
> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
> an
> option as this tomcat/java combo is the only one supported by the 
> vendor for our webapp version).
>
> Thank you!
> Brandie
>
>
>
> -
> 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 SMPT TLS1.2

[Ivano Luberti]

I had issues in the past connectin to mailserver using TLS and solved 
them upgrading the webapplicatio library from mail-1.4.jar to 
javax.mail-1.6.2.jar


Il 11/03/2024 17:41, Robert Turner ha scritto:

AFAIK, there is nothing in Tomcat for SMTP. This would be part of the
application you are running typically. It's possible (but not guaranteed)
that the web application is using the standard Java libraries for SMTP, and
as such, you may (but again not guaranteed) be able to configure some of
the mail settings via Java system properties (
https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html
).

Best bet is to work with your application provider and their
documentation / support.

Also, consider upgrading Java and Tomcat to current / supported versions as
those versions are both very old and likely have many security issues that
need patching.



On Mon, Mar 11, 2024 at 12:39 PM Jost Richstein
wrote:


Hi,

this is definitely not a Tomcat problem - take a look at:


https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary
.html



-Ursprüngliche Nachricht-
Von: Brandie Nickey
Gesendet: Montag, 11. März 2024 17:35
An:users@tomcat.apache.org
Betreff: Tomcat SMPT TLS1.2

Hi all,

I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have been
trying to find out where to configure outbound smtp messages to use only
TLS1.2.  I've found plenty of info on the https using TLS1.2 and have
configured that just fine in server.xml file and in the Java tab of the
tomcatw.exe file, but that doesn't seem to be applying to the emails
outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
an
option as this tomcat/java combo is the only one supported by the vendor
for
our webapp version).

Thank you!
Brandie



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



--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



Il contenuto di questo messaggio e dei suoi eventuali allegati è 
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di 
contattare telefonicamente o via e-mail il mittente ai recapiti sopra 
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo 
sistema senza farne copia o diffonderli. Le opinioni espresse sono 
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the 
intended recipient, please telephone or email the sender and delete this 
message and any attachment from your system. If you are not the intended 
recipient you must not copy this message or attachment or disclose the 
contents to any other person. Any opinions presented are solely those of 
the author and do not necessarily represent those of the Company.


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: Tomcat 9 returning 404 for audio files

[Ivano Luberti]

Could it be the file is created with incorrect access rights?

Il 11/03/2024 16:46, Mark Thomas ha scritto:

On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is 
created? The resources implementation can cache "not found" results 
for a short period of time.


You might want to test the code with a simple text file to determine 
whether file type is a factor (which seems unlikely but you never know).


Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns
404 error but if reloading the page, audio file is loaded properly 
and no

error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working 
without

any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' 
headers and

data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


 
bottom:0;"


    
  src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"

type="audio/mpeg" >
    
 

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



-
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


--

Archimede Informatica tratta i dati personali in conformità a quanto
stabilito dal Regolamento UE n. 2016/679 (GDPR) e dal D. Lgs. 30 giugno 
2003 n. 196

per come modificato dal D.Lgs. 10 agosto 2018 n. 101.
Informativa completa 



Il contenuto di questo messaggio e dei suoi eventuali allegati è 
riservato. Nel caso in cui Lei non sia il destinatario, La preghiamo di 
contattare telefonicamente o via e-mail il mittente ai recapiti sopra 
indicati e di cancellare il messaggio e gli eventuali allegati dal Suo 
sistema senza farne copia o diffonderli. Le opinioni espresse sono 
quelle dell'autore e non rappresentano necessariamente quelle della Società.
This message and any attachment are confidential.If you are not the 
intended recipient, please telephone or email the sender and delete this 
message and any attachment from your system. If you are not the intended 
recipient you must not copy this message or attachment or disclose the 
contents to any other person. Any opinions presented are solely those of 
the author and do not necessarily represent those of the Company.


dott. Ivano Mario Luberti

Archimede Informatica società cooperativa a r. l.
Via Gereschi 36, 56127 Pisa

tel.: +39 050/580959 | fax: +39 050/8932061

web: www.archicoop.it
linkedin: www.linkedin.com/in/ivanoluberti
facebook: www.facebook.com/archimedeinformaticapisa/

Re: Tomcat SMPT TLS1.2

[Robert Turner]

AFAIK, there is nothing in Tomcat for SMTP. This would be part of the
application you are running typically. It's possible (but not guaranteed)
that the web application is using the standard Java libraries for SMTP, and
as such, you may (but again not guaranteed) be able to configure some of
the mail settings via Java system properties (
https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary.html
).

Best bet is to work with your application provider and their
documentation / support.

Also, consider upgrading Java and Tomcat to current / supported versions as
those versions are both very old and likely have many security issues that
need patching.



On Mon, Mar 11, 2024 at 12:39 PM Jost Richstein 
wrote:

> Hi,
>
> this is definitely not a Tomcat problem - take a look at:
>
>
> https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary
> .html
> 
>
>
> -Ursprüngliche Nachricht-
> Von: Brandie Nickey 
> Gesendet: Montag, 11. März 2024 17:35
> An: users@tomcat.apache.org
> Betreff: Tomcat SMPT TLS1.2
>
> Hi all,
>
> I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have been
> trying to find out where to configure outbound smtp messages to use only
> TLS1.2.  I've found plenty of info on the https using TLS1.2 and have
> configured that just fine in server.xml file and in the Java tab of the
> tomcatw.exe file, but that doesn't seem to be applying to the emails
> outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not
> an
> option as this tomcat/java combo is the only one supported by the vendor
> for
> our webapp version).
>
> Thank you!
> Brandie
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

AW: Tomcat SMPT TLS1.2

[Jost Richstein]

Hi,

this is definitely not a Tomcat problem - take a look at: 

https://javaee.github.io/javamail/docs/api/com/sun/mail/smtp/package-summary
.html


-Ursprüngliche Nachricht-
Von: Brandie Nickey  
Gesendet: Montag, 11. März 2024 17:35
An: users@tomcat.apache.org
Betreff: Tomcat SMPT TLS1.2

Hi all,

I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have been
trying to find out where to configure outbound smtp messages to use only
TLS1.2.  I've found plenty of info on the https using TLS1.2 and have
configured that just fine in server.xml file and in the Java tab of the
tomcatw.exe file, but that doesn't seem to be applying to the emails
outgoing from the webapp.   Anyone have any ideas? (Also upgrading is not an
option as this tomcat/java combo is the only one supported by the vendor for
our webapp version).

Thank you!
Brandie



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

Tomcat SMPT TLS1.2

[Brandie Nickey]

Hi all,

I have a COTS webapp using Tomcat 8.0.43 and Java 1.8.0_121.  I have been 
trying to find out where to configure outbound smtp messages to use only 
TLS1.2.  I've found plenty of info on the https using TLS1.2 and have 
configured that just fine in server.xml file and in the Java tab of the 
tomcatw.exe file, but that doesn't seem to be applying to the emails outgoing 
from the webapp.   Anyone have any ideas? (Also upgrading is not an option as 
this tomcat/java combo is the only one supported by the vendor for our webapp 
version).

Thank you!
Brandie

Re: Tomcat 9 returning 404 for audio files

[Mark Thomas]

On 11/03/2024 11:31, Sam wrote:

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


Is there any chance of an attempt to access the file before it is 
created? The resources implementation can cache "not found" results for 
a short period of time.


You might want to test the code with a simple text file to determine 
whether file type is a factor (which seems unlikely but you never know).


Mark




On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:


On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files

playback.


When loading a page that contains an audio file. First time Tomcat

returns

404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log

entry

when I try to open the audio file first time. I can see 404 being

returned

from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:


 
bottom:0;"




  

 

I've tried relative path and full path but result is the same in both

cases.


I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



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






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

Re: [EXTERNAL] Re: Tomcat 9 returning 404 for audio files

[Robert Turner]

It's also possible you may need to support the "Range" HTTP header for
fetching parts of the audio file for playback. IIRC, we had to do that to
support the HTML 5 audio control properly.

On Mon, Mar 11, 2024 at 9:15 AM Joey Cochran  wrote:

> Thanks for replying!!
>
> Yes audio files are generated dynamically from DB.in a Servlet.
>
> I've verified that audio file exists on file system before returning the
> html code that contains audo control.
>
> I do NOT see this as a server side issue.
> This reads like a client/DOM cache of resource issue with the HTML5 audio
> control.
> simple fix could be (on the return/callback handler) to either
> refresh/reload just that tag on the DOM or even throw a whole DOM reload
> (more than one way to accomplish these, hence keeping it a pseudo code
> response)  -Hope this helps!
> -Joey
>
> On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:
>
> > On 11/03/2024 02:21, Sam wrote:
> > > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > > deployed as a war file. I'm facing a weird issue with audio files
> > playback.
> > >
> > > When loading a page that contains an audio file. First time Tomcat
> > returns
> > > 404 error but if reloading the page, audio file is loaded properly and
> no
> > > error from Tomcat.
> > >
> > > I'm using html 5 audio control to display the file.
> > >
> > > All other static resources(images, css and js files) are working
> without
> > > any issues. Only audio files are having this issue.
> > >
> > > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> > entry
> > > when I try to open the audio file first time. I can see 404 being
> > returned
> > > from server in Chrome dev tools.
> > >
> > >
> > > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers
> and
> > > data*
> > > Following is the log for 2nd attempt. This time audio is available and
> > > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > > DefaultServlet.serveResource: Serving resource
> > > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > > contentType='audio/mpeg'*
> >
> > Are the audio files generated dynamically on request?
> >
> > Mark
> >
> >
> > >
> > > Here is the audio control code:
> > >
> > > 
> > >  > >>
> > >
> > >   src="/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3"
> > > type="audio/mpeg" >
> > >
> > > 
> > > 
> > > I've tried relative path and full path but result is the same in both
> > cases.
> > >
> > > I've spent days trying to solve this but no luck :(
> > >
> > > I would really appreciate any guidance to solve this issue.
> > >
> > > Thanks!
> > >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
>

Re: [EXTERNAL] Re: Tomcat 9 returning 404 for audio files

[Joey Cochran]

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.

I do NOT see this as a server side issue.
This reads like a client/DOM cache of resource issue with the HTML5 audio 
control.
simple fix could be (on the return/callback handler) to either refresh/reload 
just that tag on the DOM or even throw a whole DOM reload (more than one way to 
accomplish these, hence keeping it a pseudo code response)  -Hope this helps!
-Joey

On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:

> On 11/03/2024 02:21, Sam wrote:
> > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > deployed as a war file. I'm facing a weird issue with audio files
> playback.
> >
> > When loading a page that contains an audio file. First time Tomcat
> returns
> > 404 error but if reloading the page, audio file is loaded properly and no
> > error from Tomcat.
> >
> > I'm using html 5 audio control to display the file.
> >
> > All other static resources(images, css and js files) are working without
> > any issues. Only audio files are having this issue.
> >
> > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> entry
> > when I try to open the audio file first time. I can see 404 being
> returned
> > from server in Chrome dev tools.
> >
> >
> > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
> > data*
> > Following is the log for 2nd attempt. This time audio is available and
> > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > DefaultServlet.serveResource: Serving resource
> > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > contentType='audio/mpeg'*
>
> Are the audio files generated dynamically on request?
>
> Mark
>
>
> >
> > Here is the audio control code:
> >
> > 
> >  >>
> >
> >   > type="audio/mpeg" >
> >
> > 
> > 
> > I've tried relative path and full path but result is the same in both
> cases.
> >
> > I've spent days trying to solve this but no luck :(
> >
> > I would really appreciate any guidance to solve this issue.
> >
> > Thanks!
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Tomcat 9 returning 404 for audio files

[Sam]

Thanks for replying!!

Yes audio files are generated dynamically from DB.in a Servlet.

I've verified that audio file exists on file system before returning the
html code that contains audo control.


On Mon, Mar 11, 2024, 5:22 a.m. Mark Thomas  wrote:

> On 11/03/2024 02:21, Sam wrote:
> > I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
> > deployed as a war file. I'm facing a weird issue with audio files
> playback.
> >
> > When loading a page that contains an audio file. First time Tomcat
> returns
> > 404 error but if reloading the page, audio file is loaded properly and no
> > error from Tomcat.
> >
> > I'm using html 5 audio control to display the file.
> >
> > All other static resources(images, css and js files) are working without
> > any issues. Only audio files are having this issue.
> >
> > I enabled the logs for DefaultServlet in Tomcat. Follwong is the log
> entry
> > when I try to open the audio file first time. I can see 404 being
> returned
> > from server in Chrome dev tools.
> >
> >
> > *09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
> > resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
> > data*
> > Following is the log for 2nd attempt. This time audio is available and
> > playable in browser. *09-Mar-2024 20:13:00.371 INFO
> > DefaultServlet.serveResource: Serving resource
> > '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
> > *09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
> > contentType='audio/mpeg'*
>
> Are the audio files generated dynamically on request?
>
> Mark
>
>
> >
> > Here is the audio control code:
> >
> > 
> >  >>
> >
> >   > type="audio/mpeg" >
> >
> > 
> > 
> > I've tried relative path and full path but result is the same in both
> cases.
> >
> > I've spent days trying to solve this but no luck :(
> >
> > I would really appreciate any guidance to solve this issue.
> >
> > Thanks!
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: contextVersion NullPointerException due to race condition

[Mark Thomas]

On 29/02/2024 13:32, FRANTS Patrick wrote:

Not sure this is the right mailing list or that it should go to dev.


users@ is fine. Generally, if you aren't sure use users@.


One of our unit tests will occasionally have a null pointer exception durin=

g shutdown. Unfortunately I have not been able to create a small reproducti=

on yet.

The scenario is as follows.

   *   SpringApplicationShutdownHook calls Tomcat.stop() and a contextVersio=

n used by a SSE request is removed through MapperListener.unregisterContext

   *   A tomcat thread processes an IOException ("Connection reset by peer")=

  exception for that SSE request and ends up in Mapper.map() and gets a null=

  result

from contextObjectToContextVersionMap.get(context). In the end this causes =

a NullPointerException in internalMapWrapper when

calling contextVersion.path.length()


This seems to be only in Tomcat 10.1.12+. Tomcat 10.1.11 does not have the =

problem.


I think I can see what the problem is.

When stopping a Context (which can happen during shutdown or during 
normal usage) Tomcat first removes the Context from the mapper to 
prevent any further requests from reaching the Context, then it stops 
the Context. That in turn stops the individual Wrappers (servlets). Note 
that that process waits for in progress requests to complete before the 
Wrapper is stopped.


The problem here is that the application won't be notified that it is 
being stopped until the Context is stopped. But RequestDistaptchers will 
start failing from the point the Context is removed from the mapper.


Without some major refactoring (and I'm not even sure that would be 
successful) I don't think we can address this. The best I think we could 
do is ensure that getRequestDispatcher(String) returns null in this 
case. Although that might just move the source of the NPE to your code.


Mark

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

Re: Tomcat not syncing existing sessions on restart

[Mark Thomas]

On 10/03/2024 16:59, Manak Bisht wrote:

On Fri, Feb 9, 2024 at 4:45 PM Mark Thomas  wrote:


Using 0.0.0.0 as the address for the receiver is going to cause
problems. I see similar issues with 11.0.x as 8.5.x. I haven't dug too
deeply into things as a) I am short of time and b) I'm not convinced
this should/could work anyway.

What seems to happen is that the use of 0.0.0.0 confuses the cluster as
to which node is which - I think because multiple nodes are using
0.0.0.0. That causes the failure of the initial state synchronisation.



Yes, this was indeed the problem. I chose 0.0.0.0 because binding to the
host's ip threw the following error -


01-Mar-2024 22:30:32.315 SEVERE [main]
org.apache.catalina.tribes.transport.nio.NioReceiver.start Unable to start
cluster receiver
  java.net.BindException: Cannot assign requested address


The full stack trace is available in my previous mail.

To identify the problem, I ran my application outside the container, where
I did not encounter the above error. This led me to investigate on the
Docker side of things. By default, a Docker container uses a bridge
network, so binding to the host's ip address from inside the container is
simply not possible even when the receiver port has been correctly mapped.
I was able to get it to work by passing the --network=host flag to my
docker create command. This puts the container inside the host's network,
essentially de-containerizing its networking.
Although this works, this is not desirable because this opens every port on
the container, increasing the surface area for security and debugging.
0.0.0.0 is a natural choice and is used by a lot of applications running on
Docker, even the official Tomcat image on Docker Hub does so.


There is no official Docker image provided by the Tomcat project.


I am no expert on Docker or Tomcat, however, I don't think this is ideal.
Docker has become so ubiquitous that I couldn't imagine deploying without
it, but using clustering makes me lose some of the benefits of it. I have
not looked into it, but this might also impact the BackupManager because it
also requires a Receiver element.

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


If this is known to essentially always not-work... should we log
something at startup?


I think this is the least that we could do, I am willing to work on this.
However, I also think that this should be looked into deeper to solve the
actual problem.


Thinking about this a little more (although I am still short on time so 
haven't investigated) I wonder if the issue is that a node needs to 
advertise to other nodes what IP address it is listening on. If if 
advertises 0.0.0.0 the other nodes have no way to contact it. Further 
(and you can look at the acceptor unlock code for the details) trying to 
determine a valid IP address to provide to other nodes is non-trivial 
(and the acceptor case is only looking at localhost, not across a network).



I understand that this discussion might be more fit for the dev mailing
list, please let me know if you think the above holds merit, and I will
move it there.


You start to get into having to separate the IP address a node listens 
on and the IP address it advertises for other nodes to contact it 
(similar to HTTP or JMX behind a proxy)


I'm not a docker expert but it looks to me from a quick Google search 
that the expectation in this case is that you should use swarm mode 
which provides an overlay network across the nodes.


Mark

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

Re: Tomcat 9 returning 404 for audio files

[Mark Thomas]

On 11/03/2024 02:21, Sam wrote:

I just upgraded a legacy application from Tomcat 7 to Tomcat 9. It's
deployed as a war file. I'm facing a weird issue with audio files playback.

When loading a page that contains an audio file. First time Tomcat returns
404 error but if reloading the page, audio file is loaded properly and no
error from Tomcat.

I'm using html 5 audio control to display the file.

All other static resources(images, css and js files) are working without
any issues. Only audio files are having this issue.

I enabled the logs for DefaultServlet in Tomcat. Follwong is the log entry
when I try to open the audio file first time. I can see 404 being returned
from server in Chrome dev tools.


*09-Mar-2024 20:12:50.747 INFO DefaultServlet.serveResource: Serving
resource '/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and
data*
Following is the log for 2nd attempt. This time audio is available and
playable in browser. *09-Mar-2024 20:13:00.371 INFO
DefaultServlet.serveResource: Serving resource
'/wav/2B916004DFE94FA40446429E1671C893_0001053.mp3' headers and data *
*09-Mar-2024 20:13:01.372 INFO DefaultServlet.serveFile:
contentType='audio/mpeg'*


Are the audio files generated dynamically on request?

Mark




Here is the audio control code:





   
 
   


I've tried relative path and full path but result is the same in both cases.

I've spent days trying to solve this but no luck :(

I would really appreciate any guidance to solve this issue.

Thanks!



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