Migrating tomcat 6 to 9 , rmi client not working

[Dhayalan Ganapathy]

 Hi,



I am trying to migrate tomcat6 with the war to tomcat 9, but rmiclient
which is running in tomcat 6 not working in tomcat9.

It throws an error  unknown protocol: war. Can you please help us to run
the application in tomcat 9?.



[image: cid:image004.jpg@01D9B641.52DEE890]









[image: cid:image003.jpg@01D9B640.9C190D70]



[image: cid:image005.png@01D9B641.52DEE890]



[image: cid:image006.png@01D9B641.52DEE890]



Thanks,

Dhayalan.G

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Christopher Schultz]

Dan,

On 7/12/23 22:58, Dan McLaughlin wrote:

Well, the deeper I get into the problem, the more complicated it gets.  I
thought I was onto something, thinking the size of the JSON might have
something to do with it, so I created a Python script to call curl POSTs
with increasingly larger JSON thinking I would eventually hit some size
limit, but what I'm seeing is that it seems to fail less with smaller JSON
files, although it will fail on just about any size. I even changed the
Python script to retry failed POSTs, which will work on over half the
second or third attempt.

So I decided to try to create a maven project to build the test war, then
start a Tomcat and Apache docker image..and I can't reproduce the issue.

My worst fear was that I was dealing with something potentially
Windows-specific, back to the drawing board.


Do you actually need a specific client? Or a specific application? If 
it's an issue with HTTP PUT/POST over an h2 connection, then you ought 
to be able to reproduce it with just the Examples web application and 
simple curl commands like:


$ dd if=/dev/random of=test-data bs=1024 count=[number of Ks you want]
$curl -v --data-binary @test-data 
'https://localhost/examples/servlets/nonblocking/bytecounter'


I'm sure Tomcat doesn't care whether the data are JSON, plain-text, or 
whatever. If your application is just consuming the bytes (which is 
likely), then anything which reads the request should trigger it.


It may be relevant HOW you are getting the data from the request. For 
example, are you calling request.getInputStream / request.getReader or 
are you calling request.getParameter* or similar? Or maybe request.getPart*?


-chris


On Wed, Jul 12, 2023 at 4:05 PM Dan McLaughlin  wrote:


Mark,

I'm working on a test case. I've built a simple spring boot war with a
rest API "jsonInput" that accepts any JSON and responds
with {"message":"OK"}. What I've determined so far is that it only happens
when you are proxying the request through Apache using mod_proxy_http2, and
the size of the JSON that you are sending has something to do with the
problem.  I can send a large JSON or a small one directly to Tomcat, which
works. If I send a small JSON through mod_proxy_http2, it also works, but
if I send the JSON that our client apps are sending, which is quite large,
it fails.

Before I spend more time on this test case, can you think of any setting
in Tomcat or mod_proxy_http2 that might cause the POST of the larger JSON
to fail?

--

Thanks,

Dan

On Wed, Jul 12, 2023 at 2:36 PM Mark Thomas  wrote:



12 Jul 2023 13:40:18 Dan McLaughlin :


I can confirm that if I switch h2 to http, everything works as
expected, change it back to h2 or h2c, and it breaks.


That makes me think it is an h2 bug in Tomcat.


Mark, Please let me know if the http2 logs weren't enough to tell you
what's happening; if not, I'll work on creating a simple standalone
reproduction using docker.


I've looked through those logs and don't see anything. Enabling debug
logs for org.apache.tomcat.util.net might help but a reproducible test
case is probably the easiest for us to work with.

If you can avoid using docker that helps as it is one less thing for us
to unpick when digging for the root cause but we can work with a docker
based reproducible test case if needed.

Mark



--

Thanks,

Dan

On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin 
wrote:


Hi Mark,

I already provided the output from org.apache.coyote.http2.level =
FINE in the very first post to this thread.   I didn't include
everything because all the header information includes things I don't
necessarily want to post publicly and because it would take a while
for me to obfuscate.  I will see if it's reproducible with a curl
command and if I can reproduce it in a standalone docker image.

I will also try with mod_proxy_http, as suggested by Chris.

Let me know if there is more logging I truncated that you need to see
that might tell you where the problem is; if I can provide it, I will.

--

Thanks,

Dan



On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  wrote:


On 11/07/2023 19:10, Dan McLaughlin wrote:

One other note, is I can switch to h2c, and it still fails, and a
packet
capture shows the entire JSON is delivered to Tomcat, and when I put
the
JSON from the packet inspection together (Packets 10199 --> 10208)
and
compare it to what the browser says was sent, they are identical.
There are
no signs of TCP retransmissions or other things you might expect to
see if
there was a networking related issue.


Hi Dan,

This looks like a possible Tomcat bug to me.

To debug futher I'd suggest the following:

Enable http2 debug logging by adding the following to
$CATALINA_BASE/conf/logging.properties

org.apache.coyote.http2.level = FINE

(that line should already be there, it just needs to be uncommented).

If you can provide a curl command or similar that triggers this issue
then please feel free to open a Bugzilla issue and attached the
script
and any 

Re: Update javax libs to Jakarta libs in Apache Taglibs.

[Christopher Schultz]

Mark,

On 7/13/23 08:08, Mark Thomas wrote:

12 Jul 2023 11:08:23 CHILUKA BHARATH :


Hi Team,

The latest Apache Taglibs(
https://tomcat.apache.org/download-taglibs.cgi#Standard-1.2.5) jar 
classes

using javax.servlet.* packages.

Do we have any information w.r.t supporting Jakarta when using this
specific jar ?

If not, is there any plan to release new jars by migrating javax 
references

to jakarta in Apache Taglibs ?.


Just run them through the Tomcat migration tool for Jakarta EE. Tomcat 
10 did that for the examples web application.


No plans I am aware of for a new release.


While this will indeed work, I think it's reasonable for the Tomcat team 
to produce an official release which supports Jakarta EE... but only if 
it's a project that we really want to continue to support.


As Thomas points-out, Glassfish has their own JSTL implementation and I 
think probably most people already use that.


Is it time to retire Tomcat JSTL? I think we should make a decision one 
way or the other and then take proper action. That either means moving 
Tomcat-taglibs to the Attic or producing a new version for the Jakarta 
EE era.


There are far too many OSS projects out there saying "yeah Jakarta EE is 
coming but nobody is using it yet so we won't bother to release a 
compatible library until adoption is up." The the trick is that adoption 
is slow precisely because all these dependencies won't move first.


-chris

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

Re: AW: Tomcat 9.0.76 Memory leak with Java 17

[Christopher Schultz]

Thomas,

On 7/13/23 02:19, Thomas Hoffmann (Speed4Trade GmbH) wrote:

Hello,


-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Mittwoch, 12. Juli 2023 21:34
An: users@tomcat.apache.org
Betreff: Re: Tomcat 9.0.76 Memory leak with Java 17

Michael,

On 7/12/23 07:33, Michael Osipov wrote:

On 2023/07/11 18:16:24 Christopher Schultz wrote:

You should report all of the previous issues to Oracle against their
ORDS version 22.1 and ask them to fix them. It's why you write those
big, fat checks in the first place ;)


This doesn't really matter. I have reported a memory leak in OJDBC
many years ago where a background thread pins the WebappClassLoader.
Answer from Oracle: This happens only once, does not repeat. We won't
address that...

Fair enough, but that doesn't mean it's not worth reporting.

BTW the fine folks at Sun/Oracle and Connector/J are similarly confused
when it comes to ClassLoader pinning in /their/ JDBC driver. I think they had a
few different patches that all waved their hands _still_ failing to actually
understand and fix the problem.

-chris



It's not just Oracle JDBC driver.
Same can happen with SQL-Server JDBC driver when you use Kerberos Auth.
Ticket was also closed without a fix.


Yeah, and I think it just comes down to failure to understand the problem.

The problem with Connector/J has always been that they launch a 
background thread to clean things up. All they have to do is provide a 
method to "shut down background threads".


I kept getting pushback like "they are daemon threads, they won't keep 
your JVM running when your application stops" and I was like "hey 
sometimes the application stops and restarts without shutting down the 
JVM #webapps" and they were like "what does that even mean CLOSED WONTFIX".


-chris

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

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Mark Thomas]

13 Jul 2023 13:31:29 Dan McLaughlin :


Mark,

Never mind the last message, I thought it was working, but I had
looked at my test balancer config and forgot I had left the
application config using http instead of h2. So it's still busted. I
am running out of time on my end to spend on this at the moment.
Since it seems to be a Windows-specific issue, it will take me a lot
longer to set up a way to reproduce it since I don't have the
flexibility of spinning up docker images.   I will be moving back to
mod_jk for now since I know that works.  If I can provide you anything
else as far as logs from our environment that might point to what's
going on without me having to create a way to reproduce it for a bug
report I'd be happy to do so, but for now, I have to get back to
working on other things on my plate.


Understood.

Can I make one final request?

Please open a BZ issue and summarise which combinations cause problems 
and which don't. OS for each component (https, Tomcat, client) and 
whether they are all on the same host is likely relevant as well as the 
usual version and config info.


I'll try and reproduce it when I have time. Worst case it will get put 
into NEEDINFO state until we can figure out how to trigger the issue.


Thanks,

Mark




--

Thanks,

Dan

On Wed, Jul 12, 2023 at 10:56 PM Dan McLaughlin  
wrote:


Hey Mark,

I found a workaround/fix.  On the Tomcat Connector, instead of using
protocol=HTTP/1.1, I changed it to
protocol="org.apache.coyote.http11.Http11Nio2Protocol," I haven't had
a single failure since. Not only that, but our application response
times are noticeably faster.

--

Thanks,

Dan
On Wed, Jul 12, 2023 at 9:58 PM Dan McLaughlin  
wrote:


Well, the deeper I get into the problem, the more complicated it 
gets.  I thought I was onto something, thinking the size of the JSON 
might have something to do with it, so I created a Python script to 
call curl POSTs with increasingly larger JSON thinking I would 
eventually hit some size limit, but what I'm seeing is that it seems 
to fail less with smaller JSON files, although it will fail on just 
about any size. I even changed the Python script to retry failed 
POSTs, which will work on over half the second or third attempt.


So I decided to try to create a maven project to build the test war, 
then start a Tomcat and Apache docker image..and I can't reproduce 
the issue.


My worst fear was that I was dealing with something potentially 
Windows-specific, back to the drawing board.


--

Thanks,

Dan

On Wed, Jul 12, 2023 at 4:05 PM Dan McLaughlin  
wrote:


Mark,

I'm working on a test case. I've built a simple spring boot war with 
a rest API "jsonInput" that accepts any JSON and responds with 
{"message":"OK"}. What I've determined so far is that it only 
happens when you are proxying the request through Apache using 
mod_proxy_http2, and the size of the JSON that you are sending has 
something to do with the problem.  I can send a large JSON or a 
small one directly to Tomcat, which works. If I send a small JSON 
through mod_proxy_http2, it also works, but if I send the JSON that 
our client apps are sending, which is quite large, it fails.


Before I spend more time on this test case, can you think of any 
setting in Tomcat or mod_proxy_http2 that might cause the POST of 
the larger JSON to fail?


--

Thanks,

Dan

On Wed, Jul 12, 2023 at 2:36 PM Mark Thomas  
wrote:



12 Jul 2023 13:40:18 Dan McLaughlin :


I can confirm that if I switch h2 to http, everything works as
expected, change it back to h2 or h2c, and it breaks.


That makes me think it is an h2 bug in Tomcat.

Mark, Please let me know if the http2 logs weren't enough to tell 
you
what's happening; if not, I'll work on creating a simple 
standalone

reproduction using docker.


I've looked through those logs and don't see anything. Enabling 
debug
logs for org.apache.tomcat.util.net might help but a reproducible 
test

case is probably the easiest for us to work with.

If you can avoid using docker that helps as it is one less thing 
for us
to unpick when digging for the root cause but we can work with a 
docker

based reproducible test case if needed.

Mark



--

Thanks,

Dan

On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin 
wrote:


Hi Mark,

I already provided the output from org.apache.coyote.http2.level 
=

FINE in the very first post to this thread.   I didn't include
everything because all the header information includes things I 
don't
necessarily want to post publicly and because it would take a 
while

for me to obfuscate.  I will see if it's reproducible with a curl
command and if I can reproduce it in a standalone docker image.

I will also try with mod_proxy_http, as suggested by Chris.

Let me know if there is more logging I truncated that you need to 
see
that might tell you where the problem is; if I can provide it, I 
will.


--

Thanks,

Dan



On Wed, Jul 12, 2023 at 3:34 AM Mark Thomas  
wrote:


On 11/07/2023 19:10, Dan McLaughlin 

Re: CVE-2023-28709 incomplete fix

[Mark Thomas]

13 Jul 2023 07:07:29 Prodan, Andreea Adriana 
:


Whether that is something which happened in the versions < 9.0.74 and 
now in the versions >= 9.0.74 is not the case anymore.


The title of that section is "Fixed in 9.0.74".

The "affects section for the CVE is "Affects: 9.0.71 to 9.0.73"

What isn't clear about the affected versions from that information?

Mark





-Original Message-
From: Mark Thomas 
Sent: Wednesday, July 12, 2023 10:25 PM
To: Tomcat Users List 
Subject: Re: CVE-2023-28709 incomplete fix


12 Jul 2023 13:23:32 Prodan, Andreea Adriana
:


Hello,

In regard to
CVE-2023-28709
we would like to know if the vulnerability caused by the incomplete
fix, "If non-default HTTP connector settings were used such that the
maxParameterCount could be reached using query string parameters and a
request was submitted that supplied exactly maxParameterCount
parameters in the query string, the limit for uploaded request parts
could be bypassed with the potential for a denial of service to
occur",  was completely fixed in the release 9.0.74 and thus is enough
just to do an upgrade to a version >= 9.0.74 to solve the issue.


Regards,> Andreea Prodan



What part of
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.74
is not sufficiently clear?

Mark

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


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


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

Re: Update javax libs to Jakarta libs in Apache Taglibs.

[Mark Thomas]

12 Jul 2023 11:08:23 CHILUKA BHARATH :


Hi Team,

The latest Apache Taglibs(
https://tomcat.apache.org/download-taglibs.cgi#Standard-1.2.5) jar 
classes

using javax.servlet.* packages.

Do we have any information w.r.t supporting Jakarta when using this
specific jar ?

If not, is there any plan to release new jars by migrating javax 
references

to jakarta in Apache Taglibs ?.


Just run them through the Tomcat migration tool for Jakarta EE. Tomcat 10 
did that for the examples web application.


No plans I am aware of for a new release.

Mark

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

Re: Angular -> Apache 2.4.57 -> Tomcat 10.1.10 over HTTP2

[Dan McLaughlin]

Mark,

Never mind the last message, I thought it was working, but I had
looked at my test balancer config and forgot I had left the
application config using http instead of h2. So it's still busted. I
am running out of time on my end to spend on this at the moment.
Since it seems to be a Windows-specific issue, it will take me a lot
longer to set up a way to reproduce it since I don't have the
flexibility of spinning up docker images.   I will be moving back to
mod_jk for now since I know that works.  If I can provide you anything
else as far as logs from our environment that might point to what's
going on without me having to create a way to reproduce it for a bug
report I'd be happy to do so, but for now, I have to get back to
working on other things on my plate.

--

Thanks,

Dan

On Wed, Jul 12, 2023 at 10:56 PM Dan McLaughlin  wrote:
>
> Hey Mark,
>
> I found a workaround/fix.  On the Tomcat Connector, instead of using
> protocol=HTTP/1.1, I changed it to
> protocol="org.apache.coyote.http11.Http11Nio2Protocol," I haven't had
> a single failure since. Not only that, but our application response
> times are noticeably faster.
>
> --
>
> Thanks,
>
> Dan
> On Wed, Jul 12, 2023 at 9:58 PM Dan McLaughlin  wrote:
> >
> > Well, the deeper I get into the problem, the more complicated it gets.  I 
> > thought I was onto something, thinking the size of the JSON might have 
> > something to do with it, so I created a Python script to call curl POSTs 
> > with increasingly larger JSON thinking I would eventually hit some size 
> > limit, but what I'm seeing is that it seems to fail less with smaller JSON 
> > files, although it will fail on just about any size. I even changed the 
> > Python script to retry failed POSTs, which will work on over half the 
> > second or third attempt.
> >
> > So I decided to try to create a maven project to build the test war, then 
> > start a Tomcat and Apache docker image..and I can't reproduce the issue.
> >
> > My worst fear was that I was dealing with something potentially 
> > Windows-specific, back to the drawing board.
> >
> > --
> >
> > Thanks,
> >
> > Dan
> >
> > On Wed, Jul 12, 2023 at 4:05 PM Dan McLaughlin  wrote:
> >>
> >> Mark,
> >>
> >> I'm working on a test case. I've built a simple spring boot war with a 
> >> rest API "jsonInput" that accepts any JSON and responds with 
> >> {"message":"OK"}. What I've determined so far is that it only happens when 
> >> you are proxying the request through Apache using mod_proxy_http2, and the 
> >> size of the JSON that you are sending has something to do with the 
> >> problem.  I can send a large JSON or a small one directly to Tomcat, which 
> >> works. If I send a small JSON through mod_proxy_http2, it also works, but 
> >> if I send the JSON that our client apps are sending, which is quite large, 
> >> it fails.
> >>
> >> Before I spend more time on this test case, can you think of any setting 
> >> in Tomcat or mod_proxy_http2 that might cause the POST of the larger JSON 
> >> to fail?
> >>
> >> --
> >>
> >> Thanks,
> >>
> >> Dan
> >>
> >> On Wed, Jul 12, 2023 at 2:36 PM Mark Thomas  wrote:
> >>>
> >>>
> >>> 12 Jul 2023 13:40:18 Dan McLaughlin :
> >>>
> >>> > I can confirm that if I switch h2 to http, everything works as
> >>> > expected, change it back to h2 or h2c, and it breaks.
> >>>
> >>> That makes me think it is an h2 bug in Tomcat.
> >>>
> >>> > Mark, Please let me know if the http2 logs weren't enough to tell you
> >>> > what's happening; if not, I'll work on creating a simple standalone
> >>> > reproduction using docker.
> >>>
> >>> I've looked through those logs and don't see anything. Enabling debug
> >>> logs for org.apache.tomcat.util.net might help but a reproducible test
> >>> case is probably the easiest for us to work with.
> >>>
> >>> If you can avoid using docker that helps as it is one less thing for us
> >>> to unpick when digging for the root cause but we can work with a docker
> >>> based reproducible test case if needed.
> >>>
> >>> Mark
> >>>
> >>> >
> >>> > --
> >>> >
> >>> > Thanks,
> >>> >
> >>> > Dan
> >>> >
> >>> > On Wed, Jul 12, 2023 at 6:00 AM Dan McLaughlin 
> >>> > wrote:
> >>> >>
> >>> >> Hi Mark,
> >>> >>
> >>> >> I already provided the output from org.apache.coyote.http2.level =
> >>> >> FINE in the very first post to this thread.   I didn't include
> >>> >> everything because all the header information includes things I don't
> >>> >> necessarily want to post publicly and because it would take a while
> >>> >> for me to obfuscate.  I will see if it's reproducible with a curl
> >>> >> command and if I can reproduce it in a standalone docker image.
> >>> >>
> >>> >> I will also try with mod_proxy_http, as suggested by Chris.
> >>> >>
> >>> >> Let me know if there is more logging I truncated that you need to see
> >>> >> that might tell you where the problem is; if I can provide it, I will.
> >>> >>
> >>> >> --
> >>> >>
> >>> >> Thanks,
> >>> >>
> >>> >> Dan
> >>> >>
> >>> >>
> >>> 

AW: Update javax libs to Jakarta libs in Apache Taglibs.

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello Bharath,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Mittwoch, 12. Juli 2023 21:51
> An: Tomcat Users List ; CHILUKA BHARATH
> 
> Betreff: Re: Update javax libs to Jakarta libs in Apache Taglibs.
> 
> Bharath,
> 
> On 7/12/23 05:08, CHILUKA BHARATH wrote:
> > The latest Apache Taglibs(
> > https://tomcat.apache.org/download-taglibs.cgi#Standard-1.2.5) jar
> > classes using javax.servlet.* packages.
> >
> > Do we have any information w.r.t supporting Jakarta when using this
> > specific jar ?
> >
> > If not, is there any plan to release new jars by migrating javax
> > references to jakarta in Apache Taglibs ?.
> 
> This is a very good question.
> 
>  From what I can tell, the latest release of taglibs (1.2.5) was released 
> back in
> 2015.
> 
> The first question I would have about this is: Does anybody still care about
> Tomcat STL? Obviously, _you_ care, but is this a project that has simply
> matured to the point that it no longer needs updates, or has it been
> abandoned? Olivier did some work back in 2020 -- including a migration from
> javax.* to jakarta.* -- but there hasn't been any meaningful activity since
> then.
> 
> Bharath, are you able to check-out the "main" branch and build it, and does it
> work for you? We could simply release what we have currently as a beta and
> get community feedback. The only question is "what community?" We rarely
> get questions on the list and I'm not sure how many potential users there
> are.
> 
> Is there a TCK for JSTL? I don't use JSP for any meaningful project myself, 
> and
> setting-up test-cases to even validate that the basics are working properly
> will be time-consuming.
> 
> -chris
> 

This package uses jakarta:
https://mvnrepository.com/artifact/jakarta.servlet.jsp.jstl/jakarta.servlet.jsp.jstl-api
The implementation is for example:
https://mvnrepository.com/artifact/org.glassfish.web/jakarta.servlet.jsp.jstl

Greetings,
Thomas

AW: Tomcat 9.0.76 Memory leak with Java 17

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Christopher Schultz 
> Gesendet: Mittwoch, 12. Juli 2023 21:34
> An: users@tomcat.apache.org
> Betreff: Re: Tomcat 9.0.76 Memory leak with Java 17
> 
> Michael,
> 
> On 7/12/23 07:33, Michael Osipov wrote:
> > On 2023/07/11 18:16:24 Christopher Schultz wrote:
> >> You should report all of the previous issues to Oracle against their
> >> ORDS version 22.1 and ask them to fix them. It's why you write those
> >> big, fat checks in the first place ;)
> >
> > This doesn't really matter. I have reported a memory leak in OJDBC
> > many years ago where a background thread pins the WebappClassLoader.
> > Answer from Oracle: This happens only once, does not repeat. We won't
> > address that...
> Fair enough, but that doesn't mean it's not worth reporting.
> 
> BTW the fine folks at Sun/Oracle and Connector/J are similarly confused
> when it comes to ClassLoader pinning in /their/ JDBC driver. I think they had 
> a
> few different patches that all waved their hands _still_ failing to actually
> understand and fix the problem.
> 
> -chris
> 

It's not just Oracle JDBC driver.
Same can happen with SQL-Server JDBC driver when you use Kerberos Auth. 
Ticket was also closed without a fix.