Re: HTTP Error 414. The request URL is too long.

[Stefan Mayr]

Am 10.03.2023 um 07:58 schrieb Thomas Hoffmann (Speed4Trade GmbH):

Hello,


-Ursprüngliche Nachricht-
Von: Seth Mayers 
Gesendet: Freitag, 10. März 2023 01:14
An: Tomcat Users List 
Betreff: Re: HTTP Error 414. The request URL is too long.

Thanks.  Sadly I know how the data is being pushed.  It is poorly architected.
Developers are working to re-write it but I am looking for a short term solution
until they can complete that project.  I found where windows is logging the
error.  I am just not sure which process writes to this log or how to tell it to
ignore the error.  I thought I had it with a registry entry but it didn't fix 
the
problem.

C:\Windows\System32\LogFiles\HTTPERR


This looks like a windows system running IIS.
IIS also has some max-settings for requests.
Maybe you can check the IIS advanced settings for this site.


This could be an IIS with mod_jk or an ARR reverse proxy. When this is 
specific to GET requests increasing MaxFieldLength for http.sys should help


Reference: 
https://learn.microsoft.com/en-US/troubleshoot/developer/webapps/iis/iisadmin-service-inetinfo/httpsys-registry-windows


It might be necessary to tune other settings but those should have 
different status codes.




2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
URL_Length -


You should keep an eye on this log entry: this is a GET request as your 
SAMPLE POST already indicated. Maybe you can check back with your 
developers that they change their code to really use the POST method



On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
wrote:


On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing

maxHttpHeaderSize as suggested on Google.  It worked for him for a
while, but he encountered the same error again later on.

Our developers got involved and later discovered that our app was
trying

to display all his favourites and the customer somehow managed to
accumulate a huge list of favourites. So, a hotfix was created to
limit the size of the favourites that get displayed on to the browser.

I hope that helps you sort it out with the application to find what
huge

data is being push onto the url and limit it.

-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running
Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?
Is something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status
code

is originating, it isn't Tomcat. It must be in the application or in a
component before Tomcat.


Mark




SAMPLE POST (the one that fails is FAR larger than this)



http://servername/gatewayAdminTest/GatewayClient?OutputType=1

Typ
e=1=

 

   LSF
   01092390
   02
   
   test_promo_freeProduct
   DROP
   
   
   01092391
   WEB001232
   O


   
  39012621
  1.0
  BAG
   

 
  

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat
access log if you can get a request that far.

-Terence Bandoian


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




--


[image: photograph]

*Seth Mayers* Chief Technology Officer
*p:*
*e:* seth.may...@petfoodexperts.com
www.petfoodexperts.com
[image: facebook icon]   [image:
instagram icon]   [image:
linkedin icon]   [image:
twitter icon]   [image: youtube icon]



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



- Stefan

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

AW: connecting tomcat server to eclipse java ee

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

as an alternative, you can also create a normal java debug configuration with 
the main class
org.apache.catalina.startup.Bootstrap

Add all the service parameters to the tab Arguments --> VM-arguments.
As a program argument I use 
-config "\server.xml" start

Add the needed Tomcat jars to the dependencies.

Greetings, Thomas

> -Ursprüngliche Nachricht-
> Von: JIM HENK 
> Gesendet: Freitag, 10. März 2023 07:58
> An: Tomcat Users List 
> Betreff: Re: connecting tomcat server to eclipse java ee
> 
> Well….
> 
> When you see that message, Eclipse has gone through it’s table of Tomcat
> version possibilities known at the time your version of Eclipse was published,
> and hasn't found it.  Must’ve come *after*.
> 
> Therefore, The version of Eclipse you need to use has got to have been 
> released
> *after* the version of Tomcat that you’ve got installed.  That way, it will 
> have
> that version of Tomcat in it’s table of known Tomcat versions it can choose
> from.
> 
> Folks, do you concur, or am I wrong here?
> 
>- Jim Henk
> 
> > On Mar 9, 2023, at 6:36 PM, Stephanie Panah
>  wrote:
> >
> > Help please. I have installed: Java EE, Eclipse and Tomcat.
> > When I try to connect the server, I encounter:
> > Unknown version of Tomcat was specified.
> > I am looking all over. please help
> >
> > Java EE for web developers
> > C:\Users\steph> java -fullversion
> > java full version "17.0.6+9-LTS-190"
> >
> > and
> > Eclipse IDE for Enterprise Java and Web Developers
> > Version: 2022-12 (4.26.0)
> > Build id: 20221201-1913
> >
> > and
> > http://localhost:8080/
> > Apache Tomcat/10.1.7
> > If you're seeing this, you've successfully installed Tomcat.
> > Congratulations!
> > C:\Program Files\Apache Software Foundation\Tomcat 10.1 and Tomcat is
> > running in Services
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

AW: --add-opens gives me unknown module

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

it seems you are using an outdated library which is not compatible to java 17.
Are there any other libraries except spring boot which might use the proxy 
class?
Best is to search for a newer version and upgrade the corresponding library.

Greetings, Thomas

> -Ursprüngliche Nachricht-
> Von: Neil Aggarwal 
> Gesendet: Freitag, 10. März 2023 05:23
> An: users@tomcat.apache.org
> Betreff: --add-opens gives me unknown module
> 
> Hey everyone:
> 
> 
> 
> I am trying to deploy a Spring Boot 3.0.4 application to a Tomcat 10.1.7
> 
> server.  The machine has java 17 installed.
> 
> 
> 
> When I try to loan tomcat, it gives me this error:
> 
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.lang.reflect.Method jdk.proxy3.$Proxy74.m0 accessible:
> module jdk.proxy3 does not "opens jdk.proxy3" to unnamed module
> @14022c95
> 
> 
> 
> It seems strange to me the module can’t pen itself.  But, I added these lines 
> in
> setenv.sh to try to work around it:
> 
> JAVA_OPTS="$JAVA_OPTS --add-opens jdk.proxy3/jdk.proxy3=ALL-UNNAMED"
> 
> export JAVA_OPTS
> 
> 
> 
> But, now, when I run tomcat, I get this:
> 
> WARNING: Unknown module: jdk.proxy3 specified to --add-opens
> 
> 
> 
> And I still get the exception.
> 
> 
> 
> Any ideas what I need to do here?
> 
> 
> 
> Thank you,
> 
>   Neil
> 
> 
> 
> --
> 
> Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com
> 
> We offer 30 year loans on single family houses!

AW: HTTP Error 414. The request URL is too long.

[Thomas Hoffmann (Speed4Trade GmbH)]

Hello,

> -Ursprüngliche Nachricht-
> Von: Seth Mayers 
> Gesendet: Freitag, 10. März 2023 01:14
> An: Tomcat Users List 
> Betreff: Re: HTTP Error 414. The request URL is too long.
> 
> Thanks.  Sadly I know how the data is being pushed.  It is poorly architected.
> Developers are working to re-write it but I am looking for a short term 
> solution
> until they can complete that project.  I found where windows is logging the
> error.  I am just not sure which process writes to this log or how to tell it 
> to
> ignore the error.  I thought I had it with a registry entry but it didn't fix 
> the
> problem.
> 
> C:\Windows\System32\LogFiles\HTTPERR

This looks like a windows system running IIS.
IIS also has some max-settings for requests.
Maybe you can check the IIS advanced settings for this site.


> 
> 2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
> URL_Length -
> 
> On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
> wrote:
> 
> > On 3/9/2023 5:47 PM, Jason Tan wrote:
> > > Hi Seth,
> > > One of my customer had the same error. We also tried increasing
> > maxHttpHeaderSize as suggested on Google.  It worked for him for a
> > while, but he encountered the same error again later on.
> > > Our developers got involved and later discovered that our app was
> > > trying
> > to display all his favourites and the customer somehow managed to
> > accumulate a huge list of favourites. So, a hotfix was created to
> > limit the size of the favourites that get displayed on to the browser.
> > > I hope that helps you sort it out with the application to find what
> > > huge
> > data is being push onto the url and limit it.
> > > -Original Message-
> > > From: Mark Thomas 
> > > Sent: Friday, March 10, 2023 9:34 AM
> > > To: users@tomcat.apache.org
> > > Subject: Re: HTTP Error 414. The request URL is too long.
> > >
> > > On 09/03/2023 20:59, Seth Mayers wrote:
> > >> I am running Apache Tomcat Version 9.0.48.
> > >>
> > >> If I post a transaction that is very large, I get the "414; The
> > >> request URL is too long".
> > >>
> > >> I have tried adding a bunch of parameters to my server.xml file but
> > >> none of them seem to work.  I have tried:
> > >> maxHttpHeaderSize="262144"
> > >> maxSavePostSize="-1"
> > >> maxPostSize="-1"
> > >> maxHttpRequestHeaderSize="262144"
> > >>
> > >> I have someone that was able to resolve the same issue running
> > >> Tomcat
> > >> 8.5 but his solution (maxhttpheadersize) did not work for me.  Did
> > >> something change between 8.5 and 9.0.48 that might affect things?
> > >> Is something involved beyond just server.xml?
> > > Tomcat 9.0.x never returns a 414 status code. Wherever that status
> > > code
> > is originating, it isn't Tomcat. It must be in the application or in a
> > component before Tomcat.
> > >
> > > Mark
> > >
> > >
> > >>
> > >> SAMPLE POST (the one that fails is FAR larger than this)
> > >>
> > >>
> http://servername/gatewayAdminTest/GatewayClient?OutputType=1
> > >> Typ
> > >> e=1= > >> name="CreateOrder">
> > >> 
> > >> 
> > >>
> > >>   LSF
> > >>   01092390
> > >>   02
> > >>   
> > >>   test_promo_freeProduct
> > >>   DROP
> > >>   
> > >>   
> > >>   01092391
> > >>   WEB001232
> > >>   O
> > >>
> > >>
> > >>   
> > >>  39012621
> > >>  1.0
> > >>  BAG
> > >>   
> > >>
> > >> 
> > >>  
> > >> 
> > >> =xxx
> > >> --
> > >>
> >
> > Are you sure that's POST request? I'd suggest looking at the Tomcat
> > access log if you can get a request that far.
> >
> > -Terence Bandoian
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> > For additional commands, e-mail: users-h...@tomcat.apache.org
> >
> >
> 
> --
> 
> 
> [image: photograph]
> 
> *Seth Mayers* Chief Technology Officer
> *p:*
> *e:* seth.may...@petfoodexperts.com
> www.petfoodexperts.com
> [image: facebook icon]   [image:
> instagram icon]   [image:
> linkedin icon]   [image:
> twitter icon]   [image: youtube icon]
> 

Re: connecting tomcat server to eclipse java ee

[JIM HENK]

Well….

When you see that message, Eclipse has gone through it’s table of Tomcat 
version possibilities known at the time your version of Eclipse was published, 
and hasn't found it.  Must’ve come *after*.

Therefore, The version of Eclipse you need to use has got to have been released 
*after* the version of Tomcat that you’ve got installed.  That way, it will 
have that version of Tomcat in it’s table of known Tomcat versions it can 
choose from.

Folks, do you concur, or am I wrong here?

   - Jim Henk

> On Mar 9, 2023, at 6:36 PM, Stephanie Panah  wrote:
> 
> Help please. I have installed: Java EE, Eclipse and Tomcat.
> When I try to connect the server, I encounter:
> Unknown version of Tomcat was specified.
> I am looking all over. please help
> 
> Java EE for web developers
> C:\Users\steph> java -fullversion
> java full version "17.0.6+9-LTS-190"
> 
> and
> Eclipse IDE for Enterprise Java and Web Developers
> Version: 2022-12 (4.26.0)
> Build id: 20221201-1913
> 
> and
> http://localhost:8080/
> Apache Tomcat/10.1.7
> If you're seeing this, you've successfully installed Tomcat.
> Congratulations!
> C:\Program Files\Apache Software Foundation\Tomcat 10.1
> and Tomcat is running in Services


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

--add-opens gives me unknown module

[Neil Aggarwal]

Hey everyone:



I am trying to deploy a Spring Boot 3.0.4 application to a Tomcat 10.1.7

server.  The machine has java 17 installed.



When I try to loan tomcat, it gives me this error:

java.lang.reflect.InaccessibleObjectException: Unable to make field private
static final java.lang.reflect.Method jdk.proxy3.$Proxy74.m0 accessible:
module jdk.proxy3 does not "opens jdk.proxy3" to unnamed module @14022c95



It seems strange to me the module can’t pen itself.  But, I added these
lines in setenv.sh to
try to work around it:

JAVA_OPTS="$JAVA_OPTS --add-opens jdk.proxy3/jdk.proxy3=ALL-UNNAMED"

export JAVA_OPTS



But, now, when I run tomcat, I get this:

WARNING: Unknown module: jdk.proxy3 specified to --add-opens



And I still get the exception.



Any ideas what I need to do here?



Thank you,

  Neil



--

Neil Aggarwal, (972) 834-1565, http://www.propfinancing.com

We offer 30 year loans on single family houses!

Re: connecting tomcat server to eclipse java ee

[Mark Eggers]

Stephanie,

On 3/9/2023 7:06 PM, Stephanie Panah wrote:

I was able to resolve the issue. I found:

https://stackoverflow.com/questions/62764029/unknown-version-of-tomcat-was-specified-with-tomcat-9-0-37
--you need to open the folder once
--It will ask you for permission to enter after which its contents will be
visible to you as well as Eclipse
--after setting up and installing Tomcat, open the folder & then try
connecting from Eclipse
--Instead of changing permissions, try this

I had to change permissions, and that took some jiggling, but I can open
and access the Tomcat folder, now

You may wish to add this to your documentation

And now, when I tried to start the Tomcat server from Eclipse (even though
it is running in Services)
I am seeing: The server cannot be started because one or more of the ports
are invalid. Open the server editor and correct the invalid ports.
I set the admin port to 8005.

After more searching, I stopped the Tomcat server in Services and tried to
start in eclipse.
omgosh, it worked. good grief.

and, thank you,
Stephanie





On Thu, Mar 9, 2023 at 6:36 PM Stephanie Panah 
wrote:



Help please. I have installed: Java EE, Eclipse and Tomcat.
When I try to connect the server, I encounter:
Unknown version of Tomcat was specified.
I am looking all over. please help

Java EE for web developers
C:\Users\steph> java -fullversion
java full version "17.0.6+9-LTS-190"

and
Eclipse IDE for Enterprise Java and Web Developers
Version: 2022-12 (4.26.0)
Build id: 20221201-1913

and
http://localhost:8080/
Apache Tomcat/10.1.7
If you're seeing this, you've successfully installed Tomcat.
Congratulations!
C:\Program Files\Apache Software Foundation\Tomcat 10.1
and Tomcat is running in Services









If you're doing development, you really do not want to run Tomcat as a 
service.


1. Download the appropriate zip file from tomcat.apache.org
2. Unzip it in a place that you have R/W access
3. Add the runtime to Eclipse

in Window->Preferences->Server->Runtime Environments
a. click on the Add button
b. open up the Apache folder
c. browse to the version of Tomcat that you want
d. select it and click on the Next button

e. click on the Browse button and browse to where you unzipped Apache Tomcat
f. select the folder, leave the default names as is
g. click finish

Now, you'll need to create a new server based on the default runtime. 
This is handy, because you can have several servers based on the default 
runtime. You can run them on different ports, have one set up for 
debugging, choose different JREs, etc.


1. Go to Window->Show View
2. Select Other
3. Type in Server in the search text
4. Select Servers
5. Click on the Open button

It will complain that you have no servers configured. I know, you're 
going why? I configured a server runtime environment, so why no server. 
That's because you can have several servers based on the same runtime 
(see above).


So:

a. create a new server - opens up a Define a New Server dialogue.
b. open the Apache folder, and select the desired Tomcat version (same 
as before)

c. give it a unique name in Server name: field
d. The server runtime environment should be populated with the one added 
above

e. click on the Next button
f. this will show you a list of projects to add - since you don't have 
any, just click Finish


Now you should see a new line in the Servers window that describes your 
server. If you double-click on the line, you'll get a nice configuration 
screen.


There are lots of things to tweak. However, you should note the following:

Server Path: .metadata\.plugins\org.eclipse.wst.server.core\tmp0

If you have more than one server, they'll be located in tmp1, tmp2, etc.

If you need to change anything besides the ports for your Tomcat server, 
create the same directory structure that you see in Tomcat under the 
tmpN directory:


bin
conf
lib
logs
temp
webapps
work

Note, you may only need to create what you need, and probably not 
webapps. It's been a while, and I'm a NetBeans person, not an Eclipse 
person.


You can add things like database drivers in the lib subdirectory. You 
should be able to see logs in the logs directory. I recommend using 
log4j2 in your applications (along with commons-logging) and log to the 
${ sys:catalina.base}/logs directory.


You can also modify the launch configuration and add the database driver 
jar that way:


a. click on Open launch configuration
b. select the Classpath tab
c. click on User Entries
d. Click on the Add External JARS.. button
f. Browse to the JAR containing the database driver and add it

You can now start, stop, and control whether or not the Tomcat server is 
launched in debug mode, all from the IDE.


I hope this is not overwhelming. I worked through some of these while 
writing this up, since I'm an Apache NetBeans person. I don't want to 
get into an IDE war, but I just like NetBeans better.


. . . . just my two cents
/mde/

Re: connecting tomcat server to eclipse java ee

[Stephanie Panah]

I was able to resolve the issue. I found:

https://stackoverflow.com/questions/62764029/unknown-version-of-tomcat-was-specified-with-tomcat-9-0-37
--you need to open the folder once
--It will ask you for permission to enter after which its contents will be
visible to you as well as Eclipse
--after setting up and installing Tomcat, open the folder & then try
connecting from Eclipse
--Instead of changing permissions, try this

I had to change permissions, and that took some jiggling, but I can open
and access the Tomcat folder, now

You may wish to add this to your documentation

And now, when I tried to start the Tomcat server from Eclipse (even though
it is running in Services)
I am seeing: The server cannot be started because one or more of the ports
are invalid. Open the server editor and correct the invalid ports.
I set the admin port to 8005.

After more searching, I stopped the Tomcat server in Services and tried to
start in eclipse.
omgosh, it worked. good grief.

and, thank you,
Stephanie





On Thu, Mar 9, 2023 at 6:36 PM Stephanie Panah 
wrote:

>
> Help please. I have installed: Java EE, Eclipse and Tomcat.
> When I try to connect the server, I encounter:
> Unknown version of Tomcat was specified.
> I am looking all over. please help
>
> Java EE for web developers
> C:\Users\steph> java -fullversion
> java full version "17.0.6+9-LTS-190"
>
> and
> Eclipse IDE for Enterprise Java and Web Developers
> Version: 2022-12 (4.26.0)
> Build id: 20221201-1913
>
> and
> http://localhost:8080/
> Apache Tomcat/10.1.7
> If you're seeing this, you've successfully installed Tomcat.
> Congratulations!
> C:\Program Files\Apache Software Foundation\Tomcat 10.1
> and Tomcat is running in Services
>
>
>
>
>

Re: connecting tomcat server to eclipse java ee

[Veliz Broncano]

Hi! You are very pretty

On Thu, Mar 9, 2023, 9:37 PM Stephanie Panah 
wrote:

> Help please. I have installed: Java EE, Eclipse and Tomcat.
> When I try to connect the server, I encounter:
> Unknown version of Tomcat was specified.
> I am looking all over. please help
>
> Java EE for web developers
> C:\Users\steph> java -fullversion
> java full version "17.0.6+9-LTS-190"
>
> and
> Eclipse IDE for Enterprise Java and Web Developers
> Version: 2022-12 (4.26.0)
> Build id: 20221201-1913
>
> and
> http://localhost:8080/
> Apache Tomcat/10.1.7
> If you're seeing this, you've successfully installed Tomcat.
> Congratulations!
> C:\Program Files\Apache Software Foundation\Tomcat 10.1
> and Tomcat is running in Services
>

connecting tomcat server to eclipse java ee

[Stephanie Panah]

Help please. I have installed: Java EE, Eclipse and Tomcat.
When I try to connect the server, I encounter:
Unknown version of Tomcat was specified.
I am looking all over. please help

Java EE for web developers
C:\Users\steph> java -fullversion
java full version "17.0.6+9-LTS-190"

and
Eclipse IDE for Enterprise Java and Web Developers
Version: 2022-12 (4.26.0)
Build id: 20221201-1913

and
http://localhost:8080/
Apache Tomcat/10.1.7
If you're seeing this, you've successfully installed Tomcat.
Congratulations!
C:\Program Files\Apache Software Foundation\Tomcat 10.1
and Tomcat is running in Services

Re: HTTP Error 414. The request URL is too long.

[Seth Mayers]

Thanks.  Sadly I know how the data is being pushed.  It is poorly
architected.  Developers are working to re-write it but I am looking for a
short term solution until they can complete that project.  I found where
windows is logging the error.  I am just not sure which process writes to
this log or how to tell it to ignore the error.  I thought I had it with a
registry entry but it didn't fix the problem.

C:\Windows\System32\LogFiles\HTTPERR

2023-03-09 23:55:40 192.168.103.30 56355 192.168.0.27 80 - GET - - 414 -
URL_Length -

On Thu, Mar 9, 2023 at 7:06 PM Terence M. Bandoian 
wrote:

> On 3/9/2023 5:47 PM, Jason Tan wrote:
> > Hi Seth,
> > One of my customer had the same error. We also tried increasing
> maxHttpHeaderSize as suggested on Google.  It worked for him for a while,
> but he encountered the same error again later on.
> > Our developers got involved and later discovered that our app was trying
> to display all his favourites and the customer somehow managed to
> accumulate a huge list of favourites. So, a hotfix was created to limit the
> size of the favourites that get displayed on to the browser.
> > I hope that helps you sort it out with the application to find what huge
> data is being push onto the url and limit it.
> > -Original Message-
> > From: Mark Thomas 
> > Sent: Friday, March 10, 2023 9:34 AM
> > To: users@tomcat.apache.org
> > Subject: Re: HTTP Error 414. The request URL is too long.
> >
> > On 09/03/2023 20:59, Seth Mayers wrote:
> >> I am running Apache Tomcat Version 9.0.48.
> >>
> >> If I post a transaction that is very large, I get the "414; The
> >> request URL is too long".
> >>
> >> I have tried adding a bunch of parameters to my server.xml file but
> >> none of them seem to work.  I have tried:
> >> maxHttpHeaderSize="262144"
> >> maxSavePostSize="-1"
> >> maxPostSize="-1"
> >> maxHttpRequestHeaderSize="262144"
> >>
> >> I have someone that was able to resolve the same issue running Tomcat
> >> 8.5 but his solution (maxhttpheadersize) did not work for me.  Did
> >> something change between 8.5 and 9.0.48 that might affect things?  Is
> >> something involved beyond just server.xml?
> > Tomcat 9.0.x never returns a 414 status code. Wherever that status code
> is originating, it isn't Tomcat. It must be in the application or in a
> component before Tomcat.
> >
> > Mark
> >
> >
> >>
> >> SAMPLE POST (the one that fails is FAR larger than this)
> >>
> >> http://servername/gatewayAdminTest/GatewayClient?OutputType=1
> >> e=1= >> name="CreateOrder">
> >> 
> >> 
> >>
> >>   LSF
> >>   01092390
> >>   02
> >>   
> >>   test_promo_freeProduct
> >>   DROP
> >>   
> >>   
> >>   01092391
> >>   WEB001232
> >>   O
> >>
> >>
> >>   
> >>  39012621
> >>  1.0
> >>  BAG
> >>   
> >>
> >> 
> >>  
> >> 
> >> =xxx
> >> --
> >>
>
> Are you sure that's POST request? I'd suggest looking at the Tomcat
> access log if you can get a request that far.
>
> -Terence Bandoian
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

-- 


[image: photograph]

*Seth Mayers* Chief Technology Officer
*p:*
*e:* seth.may...@petfoodexperts.com
www.petfoodexperts.com
[image: facebook icon]   [image:
instagram icon]   [image:
linkedin icon]   [image:
twitter icon]   [image: youtube icon]

Re: HTTP Error 414. The request URL is too long.

[Terence M. Bandoian]

On 3/9/2023 5:47 PM, Jason Tan wrote:

Hi Seth,
One of my customer had the same error. We also tried increasing 
maxHttpHeaderSize as suggested on Google.  It worked for him for a while, but 
he encountered the same error again later on.
Our developers got involved and later discovered that our app was trying to 
display all his favourites and the customer somehow managed to accumulate a 
huge list of favourites. So, a hotfix was created to limit the size of the 
favourites that get displayed on to the browser.
I hope that helps you sort it out with the application to find what huge data 
is being push onto the url and limit it.
-Original Message-
From: Mark Thomas 
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The
request URL is too long".

I have tried adding a bunch of parameters to my server.xml file but
none of them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat
8.5 but his solution (maxhttpheadersize) did not work for me.  Did
something change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status code is 
originating, it isn't Tomcat. It must be in the application or in a component 
before Tomcat.

Mark




SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1
e=1=


   
  LSF
  01092390
  02
  
  test_promo_freeProduct
  DROP
  
  
  01092391
  WEB001232
  O
   
   
  
 39012621
 1.0
 BAG
  
   

 

=xxx
--



Are you sure that's POST request? I'd suggest looking at the Tomcat 
access log if you can get a request that far.


-Terence Bandoian


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

RE: HTTP Error 414. The request URL is too long.

[Jason Tan]

Hi Seth,
One of my customer had the same error. We also tried increasing 
maxHttpHeaderSize as suggested on Google.  It worked for him for a while, but 
he encountered the same error again later on.
Our developers got involved and later discovered that our app was trying to 
display all his favourites and the customer somehow managed to accumulate a 
huge list of favourites. So, a hotfix was created to limit the size of the 
favourites that get displayed on to the browser.
I hope that helps you sort it out with the application to find what huge data 
is being push onto the url and limit it.
-Original Message-
From: Mark Thomas  
Sent: Friday, March 10, 2023 9:34 AM
To: users@tomcat.apache.org
Subject: Re: HTTP Error 414. The request URL is too long.

On 09/03/2023 20:59, Seth Mayers wrote:
> I am running Apache Tomcat Version 9.0.48.
> 
> If I post a transaction that is very large, I get the "414; The 
> request URL is too long".
> 
> I have tried adding a bunch of parameters to my server.xml file but 
> none of them seem to work.  I have tried:
> maxHttpHeaderSize="262144"
> maxSavePostSize="-1"
> maxPostSize="-1"
> maxHttpRequestHeaderSize="262144"
> 
> I have someone that was able to resolve the same issue running Tomcat 
> 8.5 but his solution (maxhttpheadersize) did not work for me.  Did 
> something change between 8.5 and 9.0.48 that might affect things?  Is 
> something involved beyond just server.xml?

Tomcat 9.0.x never returns a 414 status code. Wherever that status code is 
originating, it isn't Tomcat. It must be in the application or in a component 
before Tomcat.

Mark


> 
> 
> SAMPLE POST (the one that fails is FAR larger than this)
> 
> http://servername/gatewayAdminTest/GatewayClient?OutputType=1
> e=1= name="CreateOrder">
> 
>
>   
>  LSF
>  01092390
>  02
>  
>  test_promo_freeProduct
>  DROP
>  
>  
>  01092391
>  WEB001232
>  O
>   
>   
>  
> 39012621
> 1.0
> BAG
>  
>   
>
> 
> 
> =xxx
> --
> 

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

Re: Tomcat V8.5.85

[Nitish Khune]

The issue is fixed in latest release. Thanks @Christopher 
Schultz

From: Christopher Schultz 
Date: Tuesday, February 28, 2023 at 3:01 PM
To: users@tomcat.apache.org 
Subject: Re: Tomcat V8.5.85
Nitish,

On 2/24/23 13:50, Nitish Khune wrote:
> Since I upgraded from 8.5.84 to 8.5.85 or later, Any REST API with below 
> header throws a context mismatch exception

It would be great if you are able to download the 8.5.87
release-candidate and test whether this problem is resolved for you. If
so, please VOTE on the release! If the problem is _not_ fixed... please
VOTE (-1) on the release!

The release [VOTE] post can be found on the Tomcat development mailing
list, and you can reply back to the list with your vote.

Don't worry about who you are: anybody can vote.

-chris

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

Re: HTTP Error 414. The request URL is too long.

[Mark Thomas]

On 09/03/2023 20:59, Seth Mayers wrote:

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The request URL
is too long".

I have tried adding a bunch of parameters to my server.xml file but none of
them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat 8.5
but his solution (maxhttpheadersize) did not work for me.  Did something
change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?


Tomcat 9.0.x never returns a 414 status code. Wherever that status code 
is originating, it isn't Tomcat. It must be in the application or in a 
component before Tomcat.


Mark





SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1=1=

   
  
 LSF
 01092390
 02
 
 test_promo_freeProduct
 DROP
 
 
 01092391
 WEB001232
 O
  
  
 
39012621
1.0
BAG
 
  
   


=xxx
--



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

HTTP Error 414. The request URL is too long.

[Seth Mayers]

I am running Apache Tomcat Version 9.0.48.

If I post a transaction that is very large, I get the "414; The request URL
is too long".

I have tried adding a bunch of parameters to my server.xml file but none of
them seem to work.  I have tried:
maxHttpHeaderSize="262144"
maxSavePostSize="-1"
maxPostSize="-1"
maxHttpRequestHeaderSize="262144"

I have someone that was able to resolve the same issue running Tomcat 8.5
but his solution (maxhttpheadersize) did not work for me.  Did something
change between 8.5 and 9.0.48 that might affect things?  Is
something involved beyond just server.xml?


SAMPLE POST (the one that fails is FAR larger than this)

http://servername/gatewayAdminTest/GatewayClient?OutputType=1=1=

  
 
LSF
01092390
02

test_promo_freeProduct
DROP


01092391
WEB001232
O
 
 

   39012621
   1.0
   BAG

 
  
   

=xxx
--

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

[Mark Thomas]

On 09/03/2023 18:19, Bhavesh Mistry wrote:

Hi Mark,

Your sample application worked 204 Firefox and our application does not
work.  That leads me to believe *Application Filter *is an issue. But
should tomcat throw an exception if the response is already committed?


A call to setStatus() after the response has been committed will be a NO-OP.


 I
will try to see if I can reproduce it using a filter with the sample app
you gave me.Only one line change  (streamOutputBuffer.closed = true)
would make our application work.  So it seems to me that the application
filter is writing something after the stream is closed and this may lead to
this behavior.  I will try to reproduce using this app.   Do still consider
this application bug or a tomcat platform bug?


Definitely an application bug.

Mark



Thank you so far for your excellent support and quick responses.

Thanks,

Bhavesh



On Thu, Mar 9, 2023 at 1:14 AM Mark Thomas  wrote:


On 08/03/2023 21:32, Bhavesh Mistry wrote:

Hi  Mark,

We have a NAT rule that forwards 443 to 8443.


OK. That explains the change in port.


Trust me on that, we have a
direct connection. To rule out any networking layer issues, I did
direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a

tunnel

(https://localhost:8443/)  to bypass port 443. Yet, the issue is still
reproducible. So there is *NOTHING* in the middle that could cause this
issue.


There must be. Could be a FireFox plugin, a Filter used by the web
application, a Valve for a third-party authentication module, etc.

Try deploying this war:
https://people.apache.org/~markt/dev/no-content-test.war

It contains 2 JSPs.
index.jsp has a link to no-content.jsp
no-content.jsp just returns a 204

This works as expected, with no errors with the latest 9.0.x code,
9.0.72, Chrome and FireFox.

If it works when deployed to your server, that points to something in
the web application. If it doesn't work, that points to something in the
network and/or browser.

Mark

* Is publicly exposing tomcat enough for debugging *or do you still

need an independent application?  I can have SSH open but you will have

to

give me your private email to email credentials and public IP.

sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination
VNMS   all  --  anywhere anywhere

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination
MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp

dpt:8000


Chain DOCKER (0 references)
target prot opt source   destination
DNAT   tcp  --  anywhere anywhere tcp

dpt:8000

to:172.17.0.2:8000

Chain VNMS (1 references)
target prot opt source   destination
DNAT   tcp  --  anywhere anywhere tcp

dpt:http

to:127.0.0.1:8080
*DNAT   tcp  --  anywhere anywhere tcp
dpt:https to:127.0.0.1:8443 // this rule

Fowards

it to the 8443.*
admin@SDWAN-VOAE1:~$

On Wed, Mar 8, 2023 at 12:29 PM Mark Thomas  wrote:


On 08/03/2023 19:52, Bhavesh Mistry wrote:

Hi Mark,

It is a *direct connection* with no proxy or no reverse proxy or no

load

balancer in the middle.  We have a web app (UI) that make backend call

and

return 204 with no content and send it to the browser.  An interesting

fact

is very thing works on Chrome but not with firefox.  We have tried
everything and we looked tomcat code and we see a change log around

this

area.


That data you provided previously is not consistent with that statement.

Tomcat is listening on port 8443.

Firefox is connecting to port 443.

I have no doubt the Tomcat change to 204 handling triggered the change
in behavior you are seeing. It appears to have exposed a HTTP/2 bug
somewhere in your system.


It is hard to come up with a sample, but I will try it.  I am just

trying

to give clue which code or line causing the problem to narrow down the
issue, but it is not helping.


Tomcat isn't the root cause. A simple test here with an index JSP and a
JSP that just returns a 204 works as expected with Chrome and FireFox.

All the indications are that there is an additional component in the
system you are testing that can't handle an HTTP/2 204 response without
a body.

Mark




Thanks,

Bhavesh



On Wed, Mar 8, 2023 at 11:43 AM Mark Thomas  wrote:


On 08/03/2023 19:38, Bhavesh Mistry wrote:

I will see if I can give a sample.  But after removing JUST ONE

LINE  (

streamOutputBuffer.closed = true;) Everything seems to work. Somehow,
firefox does not like an active stream being closed (I am not 100%

what

close does).

I will try to work on a sample to reproduce this.  I hope the above

can

give you some clue as to where the issue is.

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

[Bhavesh Mistry]

Hi Mark,

Your sample application worked 204 Firefox and our application does not
work.  That leads me to believe *Application Filter *is an issue. But
should tomcat throw an exception if the response is already committed?  I
will try to see if I can reproduce it using a filter with the sample app
you gave me.Only one line change  (streamOutputBuffer.closed = true)
would make our application work.  So it seems to me that the application
filter is writing something after the stream is closed and this may lead to
this behavior.  I will try to reproduce using this app.   Do still consider
this application bug or a tomcat platform bug?

Thank you so far for your excellent support and quick responses.

Thanks,

Bhavesh



On Thu, Mar 9, 2023 at 1:14 AM Mark Thomas  wrote:

> On 08/03/2023 21:32, Bhavesh Mistry wrote:
> > Hi  Mark,
> >
> > We have a NAT rule that forwards 443 to 8443.
>
> OK. That explains the change in port.
>
> > Trust me on that, we have a
> > direct connection. To rule out any networking layer issues, I did
> > direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a
> tunnel
> > (https://localhost:8443/)  to bypass port 443. Yet, the issue is still
> > reproducible. So there is *NOTHING* in the middle that could cause this
> > issue.
>
> There must be. Could be a FireFox plugin, a Filter used by the web
> application, a Valve for a third-party authentication module, etc.
>
> Try deploying this war:
> https://people.apache.org/~markt/dev/no-content-test.war
>
> It contains 2 JSPs.
> index.jsp has a link to no-content.jsp
> no-content.jsp just returns a 204
>
> This works as expected, with no errors with the latest 9.0.x code,
> 9.0.72, Chrome and FireFox.
>
> If it works when deployed to your server, that points to something in
> the web application. If it doesn't work, that points to something in the
> network and/or browser.
>
> Mark
>
>* Is publicly exposing tomcat enough for debugging *or do you still
> > need an independent application?  I can have SSH open but you will have
> to
> > give me your private email to email credentials and public IP.
> >
> > sudo iptables -t nat -L
> > Chain PREROUTING (policy ACCEPT)
> > target prot opt source   destination
> > VNMS   all  --  anywhere anywhere
> >
> > Chain INPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain OUTPUT (policy ACCEPT)
> > target prot opt source   destination
> >
> > Chain POSTROUTING (policy ACCEPT)
> > target prot opt source   destination
> > MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp
> dpt:8000
> >
> > Chain DOCKER (0 references)
> > target prot opt source   destination
> > DNAT   tcp  --  anywhere anywhere tcp
> dpt:8000
> > to:172.17.0.2:8000
> >
> > Chain VNMS (1 references)
> > target prot opt source   destination
> > DNAT   tcp  --  anywhere anywhere tcp
> dpt:http
> > to:127.0.0.1:8080
> > *DNAT   tcp  --  anywhere anywhere tcp
> > dpt:https to:127.0.0.1:8443 // this rule
> Fowards
> > it to the 8443.*
> > admin@SDWAN-VOAE1:~$
> >
> > On Wed, Mar 8, 2023 at 12:29 PM Mark Thomas  wrote:
> >
> >> On 08/03/2023 19:52, Bhavesh Mistry wrote:
> >>> Hi Mark,
> >>>
> >>> It is a *direct connection* with no proxy or no reverse proxy or no
> load
> >>> balancer in the middle.  We have a web app (UI) that make backend call
> >> and
> >>> return 204 with no content and send it to the browser.  An interesting
> >> fact
> >>> is very thing works on Chrome but not with firefox.  We have tried
> >>> everything and we looked tomcat code and we see a change log around
> this
> >>> area.
> >>
> >> That data you provided previously is not consistent with that statement.
> >>
> >> Tomcat is listening on port 8443.
> >>
> >> Firefox is connecting to port 443.
> >>
> >> I have no doubt the Tomcat change to 204 handling triggered the change
> >> in behavior you are seeing. It appears to have exposed a HTTP/2 bug
> >> somewhere in your system.
> >>
> >>> It is hard to come up with a sample, but I will try it.  I am just
> trying
> >>> to give clue which code or line causing the problem to narrow down the
> >>> issue, but it is not helping.
> >>
> >> Tomcat isn't the root cause. A simple test here with an index JSP and a
> >> JSP that just returns a 204 works as expected with Chrome and FireFox.
> >>
> >> All the indications are that there is an additional component in the
> >> system you are testing that can't handle an HTTP/2 204 response without
> >> a body.
> >>
> >> Mark
> >>
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Bhavesh
> >>>
> >>>
> >>>
> >>> On Wed, Mar 8, 2023 at 11:43 AM Mark Thomas  wrote:
> >>>
>  On 08/03/2023 19:38, Bhavesh Mistry wrote:
> > I will see if I can give a sample.  But after removing JUST ONE
> LINE  (
> > 

Re: Apache Tomcat wire logging does not show POST data payload

[Christopher Schultz]

Aditya,

On 3/9/23 09:29, Aditya Kumar wrote:

I edited my log4j2.xml to include these lines:


 


Now in my defined serverlog I see the http wire traffic I am after. However
there is one problem. For POST requests from my Tomcat server I can only
see request/response HTTP headers. I cannot see the POST data payload.

Is there a way to get this logged too?


Tomcat doesn't have anything to do with this kind of connection or 
logging. I think you want to post your question to either the 
http-client or log4j mailing lists.


-chris

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

Apache Tomcat wire logging does not show POST data payload

[Aditya Kumar]

I edited my log4j2.xml to include these lines:





Now in my defined serverlog I see the http wire traffic I am after. However
there is one problem. For POST requests from my Tomcat server I can only
see request/response HTTP headers. I cannot see the POST data payload.

Is there a way to get this logged too?

Re: Tomcat 9.0.72 Firefox issue with 204 response (Empty Body)

[Mark Thomas]

On 08/03/2023 21:32, Bhavesh Mistry wrote:

Hi  Mark,

We have a NAT rule that forwards 443 to 8443.


OK. That explains the change in port.


Trust me on that, we have a
direct connection. To rule out any networking layer issues, I did
direct ssh -L 8443:localhost:8443 admin@10.40.207.140 and created a tunnel
(https://localhost:8443/)  to bypass port 443. Yet, the issue is still
reproducible. So there is *NOTHING* in the middle that could cause this
issue.


There must be. Could be a FireFox plugin, a Filter used by the web 
application, a Valve for a third-party authentication module, etc.


Try deploying this war:
https://people.apache.org/~markt/dev/no-content-test.war

It contains 2 JSPs.
index.jsp has a link to no-content.jsp
no-content.jsp just returns a 204

This works as expected, with no errors with the latest 9.0.x code, 
9.0.72, Chrome and FireFox.


If it works when deployed to your server, that points to something in 
the web application. If it doesn't work, that points to something in the 
network and/or browser.


Mark

  * Is publicly exposing tomcat enough for debugging *or do you still

need an independent application?  I can have SSH open but you will have to
give me your private email to email credentials and public IP.

sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source   destination
VNMS   all  --  anywhere anywhere

Chain INPUT (policy ACCEPT)
target prot opt source   destination

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source   destination
MASQUERADE  tcp  --  172.17.0.2   172.17.0.2   tcp dpt:8000

Chain DOCKER (0 references)
target prot opt source   destination
DNAT   tcp  --  anywhere anywhere tcp dpt:8000
to:172.17.0.2:8000

Chain VNMS (1 references)
target prot opt source   destination
DNAT   tcp  --  anywhere anywhere tcp dpt:http
to:127.0.0.1:8080
*DNAT   tcp  --  anywhere anywhere tcp
dpt:https to:127.0.0.1:8443 // this rule Fowards
it to the 8443.*
admin@SDWAN-VOAE1:~$

On Wed, Mar 8, 2023 at 12:29 PM Mark Thomas  wrote:


On 08/03/2023 19:52, Bhavesh Mistry wrote:

Hi Mark,

It is a *direct connection* with no proxy or no reverse proxy or no load
balancer in the middle.  We have a web app (UI) that make backend call

and

return 204 with no content and send it to the browser.  An interesting

fact

is very thing works on Chrome but not with firefox.  We have tried
everything and we looked tomcat code and we see a change log around this
area.


That data you provided previously is not consistent with that statement.

Tomcat is listening on port 8443.

Firefox is connecting to port 443.

I have no doubt the Tomcat change to 204 handling triggered the change
in behavior you are seeing. It appears to have exposed a HTTP/2 bug
somewhere in your system.


It is hard to come up with a sample, but I will try it.  I am just trying
to give clue which code or line causing the problem to narrow down the
issue, but it is not helping.


Tomcat isn't the root cause. A simple test here with an index JSP and a
JSP that just returns a 204 works as expected with Chrome and FireFox.

All the indications are that there is an additional component in the
system you are testing that can't handle an HTTP/2 204 response without
a body.

Mark




Thanks,

Bhavesh



On Wed, Mar 8, 2023 at 11:43 AM Mark Thomas  wrote:


On 08/03/2023 19:38, Bhavesh Mistry wrote:

I will see if I can give a sample.  But after removing JUST ONE LINE  (
streamOutputBuffer.closed = true;) Everything seems to work. Somehow,
firefox does not like an active stream being closed (I am not 100% what
close does).

I will try to work on a sample to reproduce this.  I hope the above can
give you some clue as to where the issue is.


Wherever the issue is, it isn't with Tomcat and it isn't with Firefox.
I've tested them locally and they work correctly.

Might you have a reverse proxy between Firefox and Tomcat?

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: Encountered java.sql.sqlexception "the url cannot be null" starting from tomcat 9.0.71

[Mark Thomas]

On 09/03/2023 05:55, Poh Wei Xiang wrote:

Hi,

Glad to hear that this is going to be fixed.

Do you have a sample context format to work with connectionstring?


You just duplicate the current setting for url to connectionString. So 
the configuration at the start of this thread becomes:







 

 




Mark




Sent from Outlook for Android


From: Mark Thomas 
Sent: Wednesday, 8 March 2023, 20:14
To: users@tomcat.apache.org 
Subject: Re: Encountered java.sql.sqlexception "the url cannot be null" 
starting from tomcat 9.0.71

On 08/03/2023 11:58, Mark Thomas wrote:

Thanks,

I am able to recreate that stack trace. I am looking into the root cause
now.


Found it.

There was a change in Commons DBCP to use "connectionString" rather than
url internally and this was mistakenly applied to the lookup of the
"url" configuration setting in DriverAdapterCPDS.

I'll get this fixed for the April round of releases.

If you need a workaround, if you add a configuration setting for
connectionString="..." that has the same vaue as url="..." that should
get things working.

Mark




Mark


On 08/03/2023 09:03, Poh Wei Xiang wrote:

Hi,

java.sql.SQLException: The url cannot be null
 java.sql.DriverManager.getConnection(Unknown Source)
 java.sql.DriverManager.getConnection(Unknown Source)
 
org.apache.tomcat.dbcp.dbcp2.cpdsadapter.DriverAdapterCPDS.getPooledConnection(DriverAdapterCPDS.java:396)
 
org.apache.tomcat.dbcp.dbcp2.datasources.InstanceKeyDataSource.testCPDS(InstanceKeyDataSource.java:1225)
 
org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource.registerPool(PerUserPoolDataSource.java:708)
 
org.apache.tomcat.dbcp.dbcp2.datasources.PerUserPoolDataSource.getPooledConnectionAndInfo(PerUserPoolDataSource.java:614)
 
org.apache.tomcat.dbcp.dbcp2.datasources.InstanceKeyDataSource.getConnection(InstanceKeyDataSource.java:206)
 com.avaya.sce.runtime.jdbc.Database.open(Database.java:93)
 
org.apache.jsp.jsp.validate_002ddb_jsp._jspService(validate_002ddb_jsp.java:721)
 org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:466)
 org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:379)
 org.apache.jasper.servlet.JspServlet.service(JspServlet.java:327)
 javax.servlet.http.HttpServlet.service(HttpServlet.java:596)
 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:209)
 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
 org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:178)
 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:153)
 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:167)
 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:90)
 
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:492)
 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:130)
 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:93)
 
org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:673)
 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
 org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:389)
 
org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:63)
 
org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:926)
 
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1791)
 
org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
 
org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
 
org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
 
org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 java.lang.Thread.run(Unknown Source)

With Regards,
Poh Wei Xiang
Senior Engineer

D: +65 6826 3865
A: 6 Serangoon North Ave 5, #03-16, Singapore 554910
W: www.nxg-c.com
Service Helpdesk: +65 6842 2300
Service Email: serv...@nxg-c.com

Follow us:


NxGen Communications, a subsidiary of TeleChoice International
Limited, a company of ST Telemedia Pte Ltd

This email is intended solely for the use of the addressee and may
contain information that is confidential or subject to legal
professional privilege. If you receive this email in