Where to begin?

[Jon]

Hi all,

I've been looking around the Tomcat site with a view to helping out in 
some way. I have read up on Apache's way of doing things and have 
downloaded and compiled the code (for Tomcat 7) in Eclipse. I've also 
signed up to the lists and sorted out the different kinds of entries 
that go to the dev list. This lead me to BugZilla where most things seem 
to be answered already.


I've also had a look at the Tomcat Wiki. I'm not sure how this is meant 
to be used or if it is used at all?


Is the project looking for help with the actual programming? If so I 
would like to help, but would also like to help others get up and 
running. As it stands the instructions are quite basic in this area.


Anyway, I'd appreciate any pointers as to where I could join in and 
where I could make myself useful.


Regards,
Jon.

Fw: v5.5.x default context support outside of server.xml

[Jon Wilmoth]

Below is the response I got from the user list after inquiring about how to 
specify the default context for a given host in v5.5.x.  If this is indeed the 
correct way to specify the default context for a host in v 5.5.x, could I 
request that one of the following be done (in order of personal preference).

1) have tomcat respect the value of the "path" context attribute regardless of 
where the context is defined (inside server.xml or in mywebappcontext.xml)

2) add an attribute to host element allowing explicit declaration of the 
default context's path.

3) Add a section to the documentation that outlines the procedure for defining 
the default context/host when the context is defined inside and outside 
server.xml (existing docs only work for when context is defined in server.xml).

Thanks,
Jon


- Forwarded Message 
From: "Caldarale, Charles R" <[EMAIL PROTECTED]>
To: Tomcat Users List 
Sent: Thursday, October 12, 2006 9:06:00 AM
Subject: RE: v5.5.x default context support outside of server.xml


> From: Jon Wilmoth [mailto:[EMAIL PROTECTED] 
> Subject: v5.5.x default context support outside of server.xml
> 
> There seems to be some conflict between different sections
> of the context config documentation that leads me to believe
> it's not possible to specify a default virtual host's context
> with an empty string "path" attribute for a context.

The doc is a bit obtuse in this area, since it wasn't fully revised from
previous levels.  To specify the default app, you must first delete the
existing webapps/ROOT directory, then install your app in webapps/ROOT
(or webapps/ROOT.war) or put your  element in
conf/[engine]/[host]/ROOT.xml.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: v5.5.x default context support outside of server.xml

[Jon Wilmoth]

Below is the response I got from the user list after inquiring about how to 
specify the default context for a given host in v5.5.x.  If this is indeed the 
correct way to specify the default context for a host in v 5.5.x, could I 
request that one of the following be done (in order of personal preference).

1) have tomcat respect the value of the "path" context attribute regardless of 
where the context is defined (inside server.xml or in mywebappcontext.xml)

2) add an attribute to host element allowing explicit declaration of the 
default context's path.

3) Add a section to the documentation that outlines the procedure for defining 
the default context/host when the context is defined inside and outside 
server.xml (existing docs only work for when context is defined in server.xml).

Also, having noticed the votes for v 6.0 (which is very cool), I have to ask if 
the "ROOT" context name trick works the same in this new release.

Thanks,
Jon


- Forwarded Message 
From: "Caldarale, Charles R" <[EMAIL PROTECTED]>
To: Tomcat Users List 
Sent: Thursday, October 12, 2006 9:06:00 AM
Subject: RE: v5.5.x default context support outside of server.xml


> From: Jon Wilmoth [mailto:[EMAIL PROTECTED] 
> Subject: v5.5.x default context support outside of server.xml
> 
> There seems to be some conflict between different sections
> of the context config documentation that leads me to believe
> it's not possible to specify a default virtual host's context
> with an empty string "path" attribute for a context.

The doc is a bit obtuse in this area, since it wasn't fully revised from
previous levels.  To specify the default app, you must first delete the
existing webapps/ROOT directory, then install your app in webapps/ROOT
(or webapps/ROOT.war) or put your  element in
conf/[engine]/[host]/ROOT.xml.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you
received this in error, please contact the sender and delete the e-mail
and its attachments from all computers.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: v5.5.x default context support outside of server.xml

[Jon Wilmoth]

I don't mind opening a issue in Bugzilla requesting tomcat respect the value of 
the "path" context attribute regardless of where the context is defined (inside 
server.xml or in mywebappcontext.xml).  I probably wouldn't be able to 
contribute a patch to make that happen though as I'm not familiar enough with.  
I was hoping that the developer community could confirm that's how it's 
(special "ROOT" context only way to specify default webapp when context is 
defined outside of server.xml) supposed to work in 5.5.x and will continue to 
work in 6.0.0.

Thanks,
Jon

- Original Message 
From: Yoav Shapira <[EMAIL PROTECTED]>
To: Tomcat Developers List 
Sent: Thursday, October 19, 2006 7:43:36 AM
Subject: Re: v5.5.x default context support outside of server.xml


Hi,
I didn't say anyone would apply stuff he submits, certainly not as-is ;)

Yoav

On 10/19/06, Remy Maucherat <[EMAIL PROTECTED]> wrote:
> Yoav Shapira wrote:
> > Jon,
> > We got your original message.  I didn't see any replies,
> > unfortunately.  If you care to submit a patch that does any of what
> > you asked for into our Bugzilla issue tracker, that'd be great.
>
> I would have to veto that.
>
> Rémy
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: v5.5.x default context support outside of server.xml

[Jon Wilmoth]

Thanks for the response!

Is it a significant change to have TC support the empty "path" context 
attribute regardless of where the context is defined (inside server.xml or in 
mywebappcontext.xml)?  Should I open two bugs?  One to document the current 
5.5.x & 6.0.x method of specifying default context outside of server.xml and 
another for consolidating the mechanism to the empty path method?

- Original Message 
From: Remy Maucherat <[EMAIL PROTECTED]>
To: Tomcat Developers List 
Sent: Thursday, October 19, 2006 8:19:13 AM
Subject: Re: v5.5.x default context support outside of server.xml


Jon Wilmoth wrote:
> will continue to work in 6.0.0

until a more elaborate web application deployer is written (if ever).

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Non-tribes based clustering in TC6

[Jon Brisbin]

Hi all,

I'm relatively new to Tomcat 6 clustering and we have a VMware-based cloud 
architecture with a few Ubuntu Linux boxes running three instances each of 
tcServer (Tomcat 6.0.20) with SimpleTcpCluster configured to replicate with 
channelSendOptions=6 and no sticky sessions. I don't want to use sticky 
sessions because I want the user load spread equally across all Tomcat nodes. 
Each Linux VM has an Apache/mod_proxy_ajp configuration that proxies all the 
other backends.

SimpleTcpCluster works okay for a while but seems to break continually after a 
certain amount of time. Replication of session data errors out, which seems to 
snowball errors throughout the cluster. It never recovers from these errors and 
stays in an error state until I restart it. Since several Apache proxy_ajp 
instances are proxying all these backend servers, I basically need a setup 
where, when a user session is created, it is persisted to a central database 
and when subsequent requests go to different Tomcat instances, that session 
data is available to it via this central DBMS. I don't want a 
multicast/Tribes-based approach because it frankly doesn't work very well and I 
don't like getting woken up at 12:30 in the morning because our production 
systems aren't accessible because the clustering has failed and rendered the 
web applications inaccessible.

I'm so fed up with the Tribes-based clustering, I've simply determined to write 
my own DBMS-backed replacement. Our cloud architecture depends on a "master" 
node to facilitate cluster communication, so I'm not at all concerned with 
depending on this server to be up. I'm not launching space shuttles here, I 
just want a system that actually works reliably without sticky sessions and 
that can be left alone for more than 2 days at a time.

What I'd like some help with is figuring out what is the absolute minimum 
functionality to make this type of clustering work? 

When a new Session is created, I would basically write a record to a database. 
I would assume I'd need to encode/serialize an object into the DB. When that 
user hits another Tomcat instance, the clustering machinery needs to load that 
object from the DB and make it look like that user has a session in that Tomcat 
instance. I don't want to track dirty sessions, I want to write everything to 
the DB backend. There's no failover or anything here because all sessions are 
always available on all nodes in the cluster on every page request. There's no 
"replication" because the sessions are always DB-backed. There's never a time 
when session data exists in a Tomcat instance's heap in isolation from the 
other servers.

Will this approach work without a lot of overhead? I'm not looking to provide 
anything more than the bare minimum of functionality to begin with. I just 
don't have time to muck about with SimpleTcpCluster any more. 

Thanks!

J. Brisbin
http://jbrisbin.com/

RewriteRule remove query string bug ?

[Jon Harper]

Hi list,
I'm using RewriteRule to remove the query string. Using this very simple
rule:
RewriteRule /foo /bar? [R,L]

results in
GET /foo?quux ->
GET /bar?

The redirect includes a spurious question mark, I expected it to be
GET /foo?quux ->
GET /bar

(tested on tomcat 8.5.15)

Looking at the code
(java/org/apache/catalina/valves/rewrite/RewriteValve.java),
It looks buggy:

int index = urlStringDecoded.indexOf("?");
[..] snip  [..]
urlStringDecoded = urlStringDecoded.substring(0,
index);
urlStringEncoded =
URLEncoder.DEFAULT.encode(urlStringDecoded,
uriCharset)
[..] snip [..]
} else if (index == urlStringEncoded.length() -
1) {
// if the ? is the last character delete
it, its only purpose was to
// prevent the rewrite module from
appending the query string
urlStringEncoded.deleteCharAt(index);
}
>From what I understand, the last block is dead code because
urlStringEncoded is the substring of the original up to index *excluded*,
so index can never been equal to urlStringEncoded.length() - 1

The code then proceeds and adds the spurious question mark to the result.

Can anyone confirm this or did I miss something ?

Cheers,
Jon

ps: The code is also wrong in comparing the index of '?' in the *decoded*
string to the length of the *encoded* string, but that's another matter.

Jon
Jon

RE: [VOTE] Release Apache Tomcat 8.5.100

[Mcalexander, Jon J.]

I know I'm not a tester, however is 8.5.100 relevant knowing that 8.5x is EOL 
at the end of the month?

Thank you!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

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

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

> -Original Message-
> From: Christopher Schultz 
> Sent: Tuesday, March 19, 2024 11:09 AM
> To: Tomcat Developers List 
> Subject: Re: [VOTE] Release Apache Tomcat 8.5.100
> 
> All,
> 
> On 3/19/24 10:23, Christopher Schultz wrote:
> > The proposed Apache Tomcat 8.5.100 release is now available for voting.
> >
> > The notable changes compared to 8.5.99 are:
> >
> > - Fix regression when reloading TLS configuration and files.
> >
> > - When restoring a saved POST request after a successful FORM
> >    authentication, ensure that neither the URI, the query string no
> >    the protocol are corrupted when restoring the request body.
> >
> > - Align error handling for Writer and OutputStream. Ensure use of
> > either
> >    once the response has been recycled triggers a NullPointerException
> >    provided that discardFacades is configured with the default value
> > of
> >    true.
> >
> > Along with lots of other bug fixes and improvements.
> >
> > For full details, see the changelog:
> > https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat
> > -
> 8.5.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtyS
> moAV
> > SiTjPT2db8olE5tsg1Pcp5wt0SEnRqO3ek_Gc2yNI74-t2phO83t-
> WxXwouIr8Sv8R32ve
> > xfP$
> >
> > It can be obtained from:
> > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tom
> > cat/tomcat-
> 8/v8.5.100/__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtySmoAVSiTj
> > PT2db8olE5tsg1Pcp5wt0SEnRqO3ek_Gc2yNI74-t2phO83t-
> WxXwouIr8Sv8RyseCXd6$
> >
> > The Maven staging repo is:
> > https://urldefense.com/v3/__https://repository.apache.org/content/repo
> > sitories/orgapachetomcat-
> 1487__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtySm
> > oAVSiTjPT2db8olE5tsg1Pcp5wt0SEnRqO3ek_Gc2yNI74-t2phO83t-
> WxXwouIr8Sv8R8
> > MLP2bU$
> >
> > The tag is:
> > https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/8.5.
> >
> 100/__;!!F9svGWnIaVPGSwU!rXnT69JeMfvxYHMbtySmoAVSiTjPT2db8olE5ts
> g1Pcp5
> > wt0SEnRqO3ek_Gc2yNI74-t2phO83t-WxXwouIr8Sv8RxxIvQsW$
> > eddcf278ad919382608ada1898b2c5b63675c6d5
> >
> > The proposed 8.5.100 release is:
> > [ ] Broken - do not release
> > [ ] Stable - go ahead and release as 8.5.100 (stable)
> 
> +1 for stable release.
> 
> The build is 100% reproducible and the unit tests pass[1] including APR on
> MacOS x86-64. Works on a vanilla servlet-based application in a development
> environment.
> 
> [1] The unit tests that fail do so due to a class format error arising from 
> the
> combination of the Eclipse compiler, the version of Java, etc.
> and can be ignored.
> 
> Details:
> * Environment
> *  Java (build):openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime
> Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server
> VM
> Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
> *  Java (test): openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime
> Environment Temurin-17.0.10+7 (build 17.0.10+7) OpenJDK 64-Bit Server
> VM
> Temurin-17.0.10+7 (build 17.0.10+7, mixed mode)
> *  OS:  Darwin 21.6.0 x86_64
> *  cc:  Apple clang version 12.0.0 (clang-1200.0.31.1)
> *  make:GNU Make 3.81
> *  OpenSSL:   OpenSSL 3.2.0 23 Nov 2023 (Library: OpenSSL 3.2.0 23
> Nov 2023)
> *  APR: 1.7.4
> *
> * Valid SHA-512 signature for apache-tomcat-8.5.100.zip
> * Valid GPG signature for apache-tomcat-8.5.100.zip
> * Valid SHA-512 signature for apache-tomcat-8.5.100.tar.gz
> * Valid GPG signature for apache-tomcat-8.5.100.tar.gz
> * Valid SHA-512 signature for apache-tomcat-8.5.100.exe
> * Valid GPG signature for apache-tomcat-8.5.100.exe
> * Valid SHA512 signature for apache-tomcat-8.5.100-src.zip

RE: [VOTE] Release Apache Tomcat 9.0.82

[Mcalexander, Jon J.]

Question Rémy,

Are we only looking at an update to Tomcat 9x or will there be updates for 8.5x 
and 10.1x as well?

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

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

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

> -Original Message-
> From: Rémy Maucherat 
> Sent: Wednesday, October 11, 2023 8:38 AM
> To: Tomcat Developers List 
> Subject: [VOTE] Release Apache Tomcat 9.0.82
> 
> The proposed Apache Tomcat 9.0.82 release is now available for voting.
> 
> The notable changes compared to 9.0.81 are:
> 
> - Correct a regression in 9.0.81 that broke the Tomcat JBDC
>connection pool
> 
> - Correct a regression in 9.0.81 that broke HTTP compression
> 
> For full details, see the changelog:
> https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat-
> 9.0.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT
> 36ULVTpP7jV6n8wLm5FZbNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpJe
> 5xZ2q$
> 
> It can be obtained from:
> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tomc
> at/tomcat-
> 9/v9.0.82/__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT36ULVTpP7jV6n8
> wLm5FZbNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpMoEPFys$
> The Maven staging repo is:
> https://urldefense.com/v3/__https://repository.apache.org/content/reposi
> tories/orgapachetomcat-
> 1461__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT36ULVTpP7jV6n8wLm5
> FZbNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpMFYXRRV$
> The tag is:
> https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/9.0.8
> 2__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT36ULVTpP7jV6n8wLm5FZ
> bNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpJBMaDgq$
> e3b341d78d8db0f74d8989412eb28cdc39b2c251
> 
> The proposed 9.0.82 release is:
> [ ] -1, Broken - do not release
> [ ] +1, Stable - go ahead and release as 9.0.82
> 
> Rémy
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional
> commands, e-mail: dev-h...@tomcat.apache.org

RE: [VOTE] Release Apache Tomcat 9.0.82

[Mcalexander, Jon J.]

Thank you!

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

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

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

> -Original Message-
> From: Rémy Maucherat 
> Sent: Wednesday, October 11, 2023 1:36 PM
> To: Tomcat Developers List 
> Subject: Re: [VOTE] Release Apache Tomcat 9.0.82
> 
> On Wed, Oct 11, 2023 at 8:27 PM Mcalexander, Jon J.
>  wrote:
> >
> > Question Rémy,
> >
> > Are we only looking at an update to Tomcat 9x or will there be updates for
> 8.5x and 10.1x as well?
> 
> There will be releases for all the branches.
> 
> Rémy
> 
> > Thanks,
> >
> > Dream * Excel * Explore * Inspire
> > Jon McAlexander
> > Senior Infrastructure Engineer
> > Asst. Vice President
> > He/His
> >
> > Middleware Product Engineering
> > Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >
> > 8080 Cobblestone Rd | Urbandale, IA 50322
> > MAC: F4469-010
> > Tel 515-988-2508 | Cell 515-988-2508
> >
> > jonmcalexan...@wellsfargo.com
> > This message may contain confidential and/or privileged information. If you
> are not the addressee or authorized to receive this for the addressee, you
> must not use, copy, disclose, or take any action based on this message or any
> information herein. If you have received this message in error, please advise
> the sender immediately by reply e-mail and delete this message. Thank you
> for your cooperation.
> >
> > > -Original Message-
> > > From: Rémy Maucherat 
> > > Sent: Wednesday, October 11, 2023 8:38 AM
> > > To: Tomcat Developers List 
> > > Subject: [VOTE] Release Apache Tomcat 9.0.82
> > >
> > > The proposed Apache Tomcat 9.0.82 release is now available for voting.
> > >
> > > The notable changes compared to 9.0.81 are:
> > >
> > > - Correct a regression in 9.0.81 that broke the Tomcat JBDC
> > >connection pool
> > >
> > > - Correct a regression in 9.0.81 that broke HTTP compression
> > >
> > > For full details, see the changelog:
> > > https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomc
> > > at-
> > >
> 9.0.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT
> > >
> 36ULVTpP7jV6n8wLm5FZbNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpJe
> > > 5xZ2q$
> > >
> > > It can be obtained from:
> > > https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/t
> > > omc
> > > at/tomcat-
> > >
> 9/v9.0.82/__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT36ULVTpP7jV6n8
> > > wLm5FZbNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpMoEPFys$
> > > The Maven staging repo is:
> > > https://urldefense.com/v3/__https://repository.apache.org/content/re
> > > posi
> > > tories/orgapachetomcat-
> > >
> 1461__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT36ULVTpP7jV6n8wLm5
> > > FZbNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpMFYXRRV$
> > > The tag is:
> > >
> https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/9.
> > > 0.8
> 2__;!!F9svGWnIaVPGSwU!qgz3a8zzVkxxVQb9NuT36ULVTpP7jV6n8wLm5FZ
> > > bNG8JwdShdJXM6DlqBwp3ruen_3EisWFr75QwpJBMaDgq$
> > > e3b341d78d8db0f74d8989412eb28cdc39b2c251
> > >
> > > The proposed 9.0.82 release is:
> > > [ ] -1, Broken - do not release
> > > [ ] +1, Stable - go ahead and release as 9.0.82
> > >
> > > Rémy
> > >
> > > 
> > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For
> > > additional commands, e-mail: dev-h...@tomcat.apache.org
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional
> commands, e-mail: dev-h...@tomcat.apache.org

RE: [ANN] New committer: Chuck Caldarale

[Mcalexander, Jon J.]

Congratulations Chuck!

From: Mark Thomas 
Sent: Wednesday, July 3, 2024 7:25 AM
To: Tomcat Developers List ; Tomcat Users List 

Subject: [ANN] New committer: Chuck Caldarale
Importance: High

On behalf of the Tomcat committers I am delighted to announce that Chuck 
Caldarale (n828cl) has been voted in as a new Tomcat committer. Please join me 
in congratulating Chuck. Kind regards, Mark 
-


On behalf of the Tomcat committers I am delighted to announce that

Chuck Caldarale (n828cl) has been voted in as a new Tomcat committer.



Please join me in congratulating Chuck.



Kind regards,



Mark



-

To unsubscribe, e-mail: 
users-unsubscr...@tomcat.apache.org

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

Re: [ANN] New committer: Dimitris Soumis

[Mcalexander, Jon J.]

Congratulations!!!

From: Jonathan S. Fisher 
Sent: Friday, July 5, 2024 6:00:30 PM
To: Tomcat Users List 
Cc: Tomcat Developers List 
Subject: Re: [ANN] New committer: Dimitris Soumis

Many new committers lately, congrats to everyone! On Fri, Jul 5, 2024 at 2: 25 
PM Mark Thomas  wrote: > > On behalf of the Tomcat 
committers I am delighted to announce that > Dimitris Soumis (dsoumis) has been


Many new committers lately, congrats to everyone!

On Fri, Jul 5, 2024 at 2:25 PM Mark Thomas  wrote:
>
> On behalf of the Tomcat committers I am delighted to announce that
> Dimitris Soumis (dsoumis) has been voted in as a new Tomcat committer.
>
> Please join me in congratulating Dimitris.
>
> Kind regards,
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>


--
Jonathan | exabr...@gmail.com
Pessimists, see a jar as half empty. Optimists, in contrast, see it as
half full.
Engineers, of course, understand the glass is twice as big as it needs to be.

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

RE: [VOTE] Release Apache Tomcat 10.1.34

[Mcalexander, Jon J.]

Thanks as always Chris!

From: Christopher Schultz 
Sent: Friday, December 6, 2024 2:46 PM
To: dev@tomcat.apache.org
Subject: Re: [VOTE] Release Apache Tomcat 10.1.34

Jon, On 12/6/24 12: 45 PM, Mcalexander, Jon J. wrote: > This won’t result in 
losing Java 11 compatability will it? We have lots of teams using Java 11 with 
Tomcat 9x and 10. 1x You'll be fine unless you: 1. Get the Tomcat source 2. 
Perform


Jon,



On 12/6/24 12:45 PM, Mcalexander, Jon J. wrote:

> This won’t result in losing Java 11 compatability will it? We have lots of 
> teams using Java 11 with Tomcat 9x and 10.1x



You'll be fine unless you:



1. Get the Tomcat source

2. Perform a unit-test build

3. Take the automatically-downloaded derby.jar and put it into your

application



I think there is a fairly low likelihood of you doing all that :)



-chris



> From: Rainer Jung mailto:rainer.j...@kippdata.de>>

> Sent: Friday, December 6, 2024 11:01 AM

> To: dev@tomcat.apache.org<mailto:dev@tomcat.apache.org>

> Subject: Re: [VOTE] Release Apache Tomcat 10.1.34

>

> Hi Chris, Am 06. 12. 24 um 17: 49 schrieb Christopher Schultz: > Rainer, > > 
> On 12/5/24 4: 57 PM, Rainer Jung wrote: >> Am 05. 12. 24 um 18: 14 schrieb 
> Christopher Schultz: >>> The proposed Apache Tomcat 10. 1. 34 release is now

>

>

> Hi Chris,

>

>

>

> Am 06.12.24 um 17:49 schrieb Christopher Schultz:

>

>> Rainer,

>

>>

>

>> On 12/5/24 4:57 PM, Rainer Jung wrote:

>

>>> Am 05.12.24 um 18:14 schrieb Christopher Schultz:

>

>>>> The proposed Apache Tomcat 10.1.34 release is now available for

>

>>>> voting.

>

>>>>

>

>>>> All committers and PMC members are kindly requested to provide a vote

>

>>>> if possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes

>

>>>> are binding. We welcome non-committer votes or comments on release

>

>>>> builds.

>

>>>>

>

>>>> The notable changes compared to 10.1.33 are:

>

>>>>

>

>>>> - Add strong ETag support for the WebDAV and default servlet, which can

>

>>>> be enabled by using the useStrongETags init parameter with a value

>

>>>> set

>

>>>> to true. The ETag generated will be a SHA-1 checksum of the resource

>

>>>> content.

>

>>>>

>

>>>> - Add support for RateLimit header fields for HTTP (RFC draft) in the

>

>>>> RateLimitFilter. Based on pull request #775 provided by Chenjp

>

>>>>

>

>>>> - Update Tomcat's fork of Commons DBCP to 2.13.0.

>

>>>>

>

>>>> For full details, see the change log:

>

>>>> https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$<https://urldefense.com/v3/__https:/nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$><https://urldefense.com/v3/__https:/nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$%3chttps:/urldefense.com/v3/__https:/nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$%3e%3e>

><https://urldefense.com/v3/__https:/nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$%3chttps:/urldefense.com/v3/__https:/nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$%3e%3e>

>>>>

>

>>>> Applications that run on Tomcat 9 and earlier will not run on Tomcat

>

>>>> 10 without changes. Java EE applications designed for Tomcat 9 and

>

>>>> earlier may be placed in the $CATALINA_BASE/webapps-javaee directory

>

>>>> and Tomcat will automatically convert them to Jakarta EE and copy

>

>>>> them to the webapps directory.

>

>>>>

>

>>>> It can be obtained from:

>

>>>> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.34/__;!!F9svGWnI

RE: [VOTE] Release Apache Tomcat 10.1.34

[Mcalexander, Jon J.]

This won’t result in losing Java 11 compatability will it? We have lots of 
teams using Java 11 with Tomcat 9x and 10.1x

Thanks,

From: Rainer Jung 
Sent: Friday, December 6, 2024 11:01 AM
To: dev@tomcat.apache.org
Subject: Re: [VOTE] Release Apache Tomcat 10.1.34

Hi Chris, Am 06. 12. 24 um 17: 49 schrieb Christopher Schultz: > Rainer, > > On 
12/5/24 4: 57 PM, Rainer Jung wrote: >> Am 05. 12. 24 um 18: 14 schrieb 
Christopher Schultz: >>> The proposed Apache Tomcat 10. 1. 34 release is now


Hi Chris,



Am 06.12.24 um 17:49 schrieb Christopher Schultz:

> Rainer,

>

> On 12/5/24 4:57 PM, Rainer Jung wrote:

>> Am 05.12.24 um 18:14 schrieb Christopher Schultz:

>>> The proposed Apache Tomcat 10.1.34 release is now available for

>>> voting.

>>>

>>> All committers and PMC members are kindly requested to provide a vote

>>> if possible. ANY TOMCAT USER MAY VOTE, though only PMC members votes

>>> are binding. We welcome non-committer votes or comments on release

>>> builds.

>>>

>>> The notable changes compared to 10.1.33 are:

>>>

>>> - Add strong ETag support for the WebDAV and default servlet, which can

>>>be enabled by using the useStrongETags init parameter with a value

>>> set

>>>to true. The ETag generated will be a SHA-1 checksum of the resource

>>>content.

>>>

>>> - Add support for RateLimit header fields for HTTP (RFC draft) in the

>>>RateLimitFilter. Based on pull request #775 provided by Chenjp

>>>

>>> - Update Tomcat's fork of Commons DBCP to 2.13.0.

>>>

>>> For full details, see the change log:

>>> https://urldefense.com/v3/__https://nightlies.apache.org/tomcat/tomcat-10.1.x/docs/changelog.html__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXGYqmVBt$

>>>

>>> Applications that run on Tomcat 9 and earlier will not run on Tomcat

>>> 10 without changes. Java EE applications designed for Tomcat 9 and

>>> earlier may be placed in the $CATALINA_BASE/webapps-javaee directory

>>> and Tomcat will automatically convert them to Jakarta EE and copy

>>> them to the webapps directory.

>>>

>>> It can be obtained from:

>>> https://urldefense.com/v3/__https://dist.apache.org/repos/dist/dev/tomcat/tomcat-10/v10.1.34/__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXA1eSrjE$

>>>

>>> The Maven staging repo is:

>>> https://urldefense.com/v3/__https://repository.apache.org/content/repositories/orgapachetomcat-1525__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXPCqj3XD$

>>>

>>> The tag is:

>>> https://urldefense.com/v3/__https://github.com/apache/tomcat/tree/10.1.34__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXJp9CmIn$

>>> https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/__;!!F9svGWnIaVPGSwU!sGQBQTopvD1IYYdnFkc2MPo046cPfRGGdKCf14tU-oL_5yMqWDyiwokSRbw6-_vuhqIEIzMto1zEEBf9HZuipLDxXPam2zub$

>>> acf7da1801a4751b282a70ced24b73c1046db831

>>>

>>> Please reply with a +1 for release or +0/-0/-1 with an explanation.

>>

>> At least three test classes fail when testing with Java 11:

>>

>> org.apache.catalina.valves.TestJDBCAccessLogValve

>> org.apache.catalina.session.TestPersistentManagerDataSourceStore

>> org.apache.catalina.servlets.TestWebdavPropertyStore

>>

>> java.sql.SQLException: org/apache/derby/jdbc/EmbeddedDriver has been

>> compiled by a more recent version of the Java Runtime (class file

>> version 61.0), this version of the Java Runtime only recognizes class

>> file versions up to 55.0

>

> Aw.

>

> It looks like this version bump happened in May, updating to Derby

> 10.16.1.1. Derby 10.16 only supports Java 17 and later.

>

> Since Derby is only used for testing, I think it's probably to say that

> this is okay to not block the release. Had Java 11 worked between May

> and now