Updated Tomcat from 6.0.13 to 9.0.73 on IBMi, now the submitting job stays active.

[j...@nosnow.us]

Hello,
 
Our start process is a simple command that will submit a batch job that will 
use the qshell command to run the startup.sh script.
 
In version 6.0.13 this would leave 1 job running, QP0ZSPWT, running the 
application.
In version 9.0.73 we have 2 jobs now running, QP0ZSPWT and the submitting job 
with the qshell commands.
 
We have both versions running on IBM i V7R3 systems. So that rules out qshell 
issues.
 
I am hoping someone knows a way to get the submitting job to end, without 
ending the application. 
Does anyone have any experience with this type of issue?
 
Thank you!
Jean

RE: Tomcat 8.5.85 and above - Issue with file uploads

[William L. Cunningham]

Thanks, yes it happens with any file upload.

-Original Message-
From: Mark Thomas  
Sent: Friday, April 14, 2023 9:36 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat 8.5.85 and above - Issue with file uploads

WARNING: This email originated from an external source. Please be careful when 
clicking on any links in external emails.

On 13/04/2023 21:40, William L. Cunningham wrote:
> Environment:  Windows 2019 Standard with latest JDK 17 and Apache Tomcat 
> 8.5.87.
>
> When trying to upload a file to the application running off Tomcat (custom 
> software), we are getting the following error since 8.5.85 (works fine on 
> 8.5.84).
>
> ERROR [2023-04-13 15:20:20]: 
> com.company.dataimporter.servlet.FileUpload::doPost::85 Cannot delete 
> C:\Program Files\Apache Software Foundation\Tomcat 
> 8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_4
> 4d3_aee6_28d1d7989727_.tmp
> java.lang.IllegalStateException: Cannot delete C:\Program Files\Apache 
> Software Foundation\Tomcat 
> 8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
>   at 
> org.apache.tomcat.util.http.fileupload.disk.DiskFileItem.delete(DiskFi
> leItem.java:428) ~[tomcat-coyote.jar:8.5.87]
>
> This same procedure works perfectly fine in 8.5.84.  It was something 
> introduced with 8.5.85.  It also works fine on a Linux hosted version 
> (Centos) for 8.5.84 and above.  So it appears to be Windows centric.
>
> When I watch the procedure in the Catalina\localhost\company folder on 
> 8.5.84, I see the tmp file generated and then immediately deleted (it's a 
> small upload).  On 8.5.85 and above, it's locked and can't be deleted.  Thus 
> causing the error.
>
> Anyone have any thoughts?

Tomcat 8.5.85 includes an updated version of the Commons FileUpload code that 
throws an ISE if the temporary file can't be deleted.

https://github.com/apache/tomcat/commit/8d21b9ef4ae30f6f6474f00a72887338a5b745ac

It looks like this may have exposed an underlying Commons IO bug:

https://issues.apache.org/jira/browse/IO-788

Do you see this problem every time you try to upload a file?

Mark

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

RE: Tomcat 9.0.73 - Exception while accessing application

[jonmcalexander]

I will have them check but this would not be normal for our installations.

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: Mark Thomas 
> Sent: Friday, April 14, 2023 9:19 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat 9.0.73 - Exception while accessing application
> 
> On 12/04/2023 20:07, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > I have an application team that started receiving the following Exception:
> >
> > 11-Apr-2023 09:26:01.396 SEVERE [https-jsse-nio-0.0.0.0-11510-exec-19]
> org.apache.catalina.core.StandardHostValve.custom Exception Processing
> ErrorPage[exceptionType=java.lang.Exception,
> location=/jsp/sendMessage.jsp]
> >  java.lang.NoSuchFieldError: EMPTY_CHAR_ARRAY
> >  at
> org.apache.catalina.core.ApplicationContext.getRequestDispatcher(Applicati
> onContext.java:459)
> > at
> org.apache.catalina.core.ApplicationContextFacade.getRequestDispatcher(A
> pplicationContextFacade.java:215)
> > at
> org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java
> :343)
> > at
> > org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve
> > .java:302)
> >
> > If did NOT do this with 9.0.70.
> >
> > We know that it may be something that changed between 9.0.70 and
> 9.0.73, but we don't know.
> 
> The field org.apache.tomcat.util.buf.MessageBytes.EMPTY_CHAR_ARRAY
> was added.
> 
> It looks like you are trying to use JARs from different versions of Tomcat. 
> You
> can sometimes get away with doing that. This isn't one of those times.
> 
> You need to fix the 9.0.73 install so it is using all the 9.0.73 JARs and none
> from earlier Tomcat versions.
> 
> Mark
> 
> >
> > So far searching the Google isn't giving us much information, so reaching
> out to the experts.
> >
> > 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.
> >
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Session loss with filter enabled

[Kevin Huntly]

Trying to make a PCI-DSS compliant installation. It looks like this filter
does everything that Apache can do with config files, so I'll leave it out.


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Fri, Apr 14, 2023 at 10:21 AM Mark Thomas  wrote:

> On 13/04/2023 23:03, Kevin Huntly wrote:
> > Hello,
> > With this filter enabled in Tomcat's web.xml:
> >
> >  
> >  httpHeaderSecurity
> >
> >
> org.apache.catalina.filters.HttpHeaderSecurityFilter
> >  true
> >  
> >
> > My sessions are being immediately lost. If I comment out the filter,
> > everythis is fine. What does this filter actually do,
>
>
> https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java
>
>
> > and is it required if
> > the front-end webserver already handles hsts?
>
> That depends on why you added the filter. What features were you trying
> to enable?
>
> Mark
>
>
> > 
> >
> > Kevin Huntly
> > Email: kmhun...@gmail.com
> > Cell: 716/424-3311
> > 
> >
> > -BEGIN GEEK CODE BLOCK-
> > Version: 1.0
> > GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
> > W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
> > PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
> > G++ e(+) h--- r+++ y+++*
> > --END GEEK CODE BLOCK--
> >
>

Re: Clustering issue

[Kevin Huntly]

Hi Mark,

My webapp context makes no mention of the Manager or any kind of session
manager - it is only referenced in the global context.xml


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Fri, Apr 14, 2023 at 10:43 AM Mark Thomas  wrote:

> On 13/04/2023 00:20, Kevin Huntly wrote:
> > Hello Everyone,
> >
> > I setup a quick and dirty cluster following
> >
> > https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html
> >
> > I am seeing the following:
> > 12-Apr-2023 19:18:00.369 WARNING [main]
> > org.apache.catalina.ha.tcp.SimpleTcpCluster.registerManager Manager
> >
> [PersistentManager[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/esolutions]]]
> > does not implement ClusterManager, addition to cluster has been aborted.
>
> You have an Context (web application deployed at /esolutions) with an
> explicit Manager configured. If you do that, it needs to implement
> ClusterManager else the Context can't be clustered.
>
> Contexts that don't have an explicit manager configured get a cluster
> defined default if clustering is enabled and the StandardManager if
> clustering is not enabled.
>
> > And
> >
> > 12-Apr-2023 19:17:52.652 SEVERE [main]
> > org.apache.catalina.ha.deploy.FarmWarDeployer.start FarmWarDeployer can
> > only work as host cluster subelement!
>
> You added the cluster at the engine level so you can't use the
> FarmWarDeployer. You need to remove that section - or move the Cluster
> definition to inside the Host.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Tomcat Manager App and Federation

[Robert Hicks]

Does the manager app support something like Apache CXF to authenticate
people to the manager application or is the manager application only
accessible through username/password?

Robert

Re: Clustering issue

[Mark Thomas]

On 13/04/2023 00:20, Kevin Huntly wrote:

Hello Everyone,

I setup a quick and dirty cluster following

https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

I am seeing the following:
12-Apr-2023 19:18:00.369 WARNING [main]
org.apache.catalina.ha.tcp.SimpleTcpCluster.registerManager Manager
[PersistentManager[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/esolutions]]]
does not implement ClusterManager, addition to cluster has been aborted.


You have an Context (web application deployed at /esolutions) with an 
explicit Manager configured. If you do that, it needs to implement 
ClusterManager else the Context can't be clustered.


Contexts that don't have an explicit manager configured get a cluster 
defined default if clustering is enabled and the StandardManager if 
clustering is not enabled.



And

12-Apr-2023 19:17:52.652 SEVERE [main]
org.apache.catalina.ha.deploy.FarmWarDeployer.start FarmWarDeployer can
only work as host cluster subelement!


You added the cluster at the engine level so you can't use the 
FarmWarDeployer. You need to remove that section - or move the Cluster 
definition to inside the Host.


Mark

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

Re: Tomcat 8.5.85 and above - Issue with file uploads

[Mark Thomas]

On 13/04/2023 21:40, William L. Cunningham wrote:

Environment:  Windows 2019 Standard with latest JDK 17 and Apache Tomcat 8.5.87.

When trying to upload a file to the application running off Tomcat (custom 
software), we are getting the following error since 8.5.85 (works fine on 
8.5.84).

ERROR [2023-04-13 15:20:20]: 
com.company.dataimporter.servlet.FileUpload::doPost::85 Cannot delete 
C:\Program Files\Apache Software Foundation\Tomcat 
8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
java.lang.IllegalStateException: Cannot delete C:\Program Files\Apache Software 
Foundation\Tomcat 
8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
  at 
org.apache.tomcat.util.http.fileupload.disk.DiskFileItem.delete(DiskFileItem.java:428)
 ~[tomcat-coyote.jar:8.5.87]

This same procedure works perfectly fine in 8.5.84.  It was something 
introduced with 8.5.85.  It also works fine on a Linux hosted version (Centos) 
for 8.5.84 and above.  So it appears to be Windows centric.

When I watch the procedure in the Catalina\localhost\company folder on 8.5.84, 
I see the tmp file generated and then immediately deleted (it's a small 
upload).  On 8.5.85 and above, it's locked and can't be deleted.  Thus causing 
the error.

Anyone have any thoughts?


Tomcat 8.5.85 includes an updated version of the Commons FileUpload code 
that throws an ISE if the temporary file can't be deleted.


https://github.com/apache/tomcat/commit/8d21b9ef4ae30f6f6474f00a72887338a5b745ac

It looks like this may have exposed an underlying Commons IO bug:

https://issues.apache.org/jira/browse/IO-788

Do you see this problem every time you try to upload a file?

Mark

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

Re: Clustering issue

[Kevin Huntly]

within the engine but outside the host

On Fri, Apr 14, 2023, 10:23 Mark Thomas  wrote:

> On 13/04/2023 23:28, Kevin Huntly wrote:
> > Hi Chris,
> >
> > The configuration in the link I shared is what I used - copy/paste - I
> want
> > to see it working before I break it =)
>
> And where in server.xml did you add that configuration?
>
> Mark
>
> > 
> >
> > Kevin Huntly
> > Email: kmhun...@gmail.com
> > Cell: 716/424-3311
> > 
> >
> > -BEGIN GEEK CODE BLOCK-
> > Version: 1.0
> > GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
> > W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
> > PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
> > G++ e(+) h--- r+++ y+++*
> > --END GEEK CODE BLOCK--
> >
> >
> > On Thu, Apr 13, 2023 at 2:13 PM Christopher Schultz <
> > ch...@christopherschultz.net> wrote:
> >
> >> Kevin,
> >>
> >> On 4/12/23 19:20, Kevin Huntly wrote:
> >>> I setup a quick and dirty cluster following
> >>>
> >>> https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html
> >>>
> >>> I am seeing the following:
> >>> 12-Apr-2023 19:18:00.369 WARNING [main]
> >>> org.apache.catalina.ha.tcp.SimpleTcpCluster.registerManager Manager
> >>>
> >>
> [PersistentManager[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/esolutions]]]
> >>> does not implement ClusterManager, addition to cluster has been
> aborted.
> >>>
> >>> And
> >>>
> >>> 12-Apr-2023 19:17:52.652 SEVERE [main]
> >>> org.apache.catalina.ha.deploy.FarmWarDeployer.start FarmWarDeployer can
> >>> only work as host cluster subelement!
> >>>
> >>> Not sure what I've done wrong
> >>
> >> Cluster config?
> >>
> >> -chris
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> >> For additional commands, e-mail: users-h...@tomcat.apache.org
> >>
> >>
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Is Microsoft's spring-cloud-azure-starter-active-directory for Spring Boot 3 / Spring 6 compatible with Tomcat 10?

[BRUNO MELLONI]

That is the curious bit.  Nothing was needed in the previous version, and I 
found nothing mentioned for the latest version.
For my own logging (not needed before and presumably not now for the Azure 
stuff) I would use:

  org.apache.logging.log4j
  log4j-api
  ${log4j2.version}


  org.apache.logging.log4j
  log4j-core
  ${log4j2.version}


  org.apache.logging.log4j
  log4j-slf4j-impl
  ${log4j2.version}


  org.slf4j
  slf4j-api
  ${slf4j.version}


But it must have been a bug on spring-cloud-azure-starter-active-directory 
after all.  That is what was causing the logback exception, the problem would 
not happen without that dependency.   Interestingly… that particular problem 
went away this morning.  I noticed that when I did a clean build today (did not 
happen before during previous clean builds) a number of dependencies got 
downloaded/updated, and now the exception is not being thrown.

The particular problem is now solved, with no action from my part.  There are 
new issues but those I can handle.

From: Mark Thomas 
Sent: Friday, April 14, 2023 9:13 AM
To: users@tomcat.apache.org
Subject: Re: Is Microsoft's spring-cloud-azure-starter-active-directory for 
Spring Boot 3 / Spring 6 compatible with Tomcat 10?

On 13/04/2023 22: 48, BRUNO MELLONI wrote: > After further research let me ask 
the question in a different way: > > > * Tomcat 10 is configured to do log4j2 
logging. > * My log4j2 code works fine. > * 
Spring-cloud-azure-starter-active-directory
ZjQcmQRYFpfptBannerStart
CAUTION: This Message Is From an External Source
This message originated outside the Chickasaw Nation. Do not click links or 
open attachments unless you recognize the sender and know the content is safe!
Report Suspicious  

   ‌
ZjQcmQRYFpfptBannerEnd

On 13/04/2023 22:48, BRUNO MELLONI wrote:

> After further research let me ask the question in a different way:

>

>

>*   Tomcat 10 is configured to do log4j2 logging.

>*   My log4j2 code works fine.

>*   Spring-cloud-azure-starter-active-directory seems to use logback and 
> it is incompatible with my Tomcat 10 setup.

>

> Given the above… what do I need to add to Tomcat 10 to make it handle apps 
> that use logback for logging but still use my log4j2 Tomcat configuration for 
> the actual logging?



Whatever the logback documentation says you need to add to route logging

to log4j2.



> I would swear that Tomcat had slf4j and other logging translation libraries 
> built in…



Nope. That has never been the case.



> but perhaps Tomcat 10 no longer does for some and requires adding some jars?



Tomcat's internal logging routes to java.util.logging - you can re-route

that if required. Follow the directions to do that provided with your

logging framework of choice.



Assuming you are still seeing the:



"Cannot cast

ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to

jakarta.servlet.ServletContainerInitializer" error, I'll repeat my

previous question:



Which version of which JAR is that ServletContainerInitializer coming from?



Mark





>

> b.

>

> From: Mark Thomas mailto:ma...@apache.org>>

> Sent: Tuesday, April 11, 2023 2:41 PM

> To: users@tomcat.apache.org

> Subject: Re: Is Microsoft's spring-cloud-azure-starter-active-directory for 
> Spring Boot 3 / Spring 6 compatible with Tomcat 10?

>

> On 11/04/2023 20: 28, BRUNO MELLONI wrote: > I was able to migrate 
> applications to Spring Boot 3 / Spring 6 (standalone or running on Tomcat 10) 
> so long as authentication was NOT through Azure AD. > > But when I tried to 
> migrate applications

> ZjQcmQRYFpfptBannerStart

> CAUTION: This Message Is From an External Source

> This message originated outside the Chickasaw Nation. Do not click links or 
> open attachments unless you recognize the sender and know the content is safe!

>  Report Suspicious  
> 
>‌

> ZjQcmQRYFpfptBannerEnd

>

> On 11/04/2023 20:28, BRUNO MELLONI wrote:

>

>> I was able to migrate applications to Spring Boot 3 / Spring 6 (standalone 
>> or running on Tomcat 10) so long as authentication was NOT through Azure AD.

>

>>

>

>> But when I tried to migrate applications that used Microsoft's 
>> spring-cloud-azure-starter-active-directory for authentication of 2-step 
>> authenticated webapps (the preferred approach) I started to get this error 
>> during application deploy to Tomcat 10:

>

>>

>

>> Cannot cast 
>> ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to 
>> jakarta.servlet.ServletContainerInitializer

>

>>

>

>>

>

>> My suspicion is that Microsoft's latest implementation is not 

Re: Encountered java.sql.sqlexception "the url cannot be null" starting from tomcat 9.0.71

[Mark Thomas]

On 14/04/2023 04:59, Poh Wei Xiang wrote:

Hi,

Am I right to say this statement in 9.0.74 changelog is referring to the fix 
for the below issue?

Update the internal fork of Commons DBCP to f131286 (2023-03-08, 
2.10.0-SNAPSHOT). This corrects a regression introduced in 9.0.71. (markt)


Yes.

Mark




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 error, please immediately notify the sender and 
delete the email.

-Original Message-
From: Poh Wei Xiang 
Sent: Thursday, March 9, 2023 1:56 PM
To: Tomcat Users List 
Cc: Ong Han Sheng 
Subject: Re: Encountered java.sql.sqlexception "the url cannot be null" 
starting from tomcat 9.0.71

Hi,

Glad to hear that this is going to be fixed.

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

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)
 

Re: Clustering issue

[Mark Thomas]

On 13/04/2023 23:28, Kevin Huntly wrote:

Hi Chris,

The configuration in the link I shared is what I used - copy/paste - I want
to see it working before I break it =)


And where in server.xml did you add that configuration?

Mark




Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--


On Thu, Apr 13, 2023 at 2:13 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Kevin,

On 4/12/23 19:20, Kevin Huntly wrote:

I setup a quick and dirty cluster following

https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

I am seeing the following:
12-Apr-2023 19:18:00.369 WARNING [main]
org.apache.catalina.ha.tcp.SimpleTcpCluster.registerManager Manager


[PersistentManager[StandardEngine[Catalina].StandardHost[localhost].StandardContext[/esolutions]]]

does not implement ClusterManager, addition to cluster has been aborted.

And

12-Apr-2023 19:17:52.652 SEVERE [main]
org.apache.catalina.ha.deploy.FarmWarDeployer.start FarmWarDeployer can
only work as host cluster subelement!

Not sure what I've done wrong


Cluster config?

-chris

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






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

Re: Session loss with filter enabled

[Mark Thomas]

On 13/04/2023 23:03, Kevin Huntly wrote:

Hello,
With this filter enabled in Tomcat's web.xml:

 
 httpHeaderSecurity

org.apache.catalina.filters.HttpHeaderSecurityFilter
 true
 

My sessions are being immediately lost. If I comment out the filter,
everythis is fine. What does this filter actually do,


https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/filters/HttpHeaderSecurityFilter.java



and is it required if
the front-end webserver already handles hsts?


That depends on why you added the filter. What features were you trying 
to enable?


Mark





Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--



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

Re: Tomcat 9.0.73 - Exception while accessing application

[Mark Thomas]

On 12/04/2023 20:07, jonmcalexan...@wellsfargo.com.INVALID wrote:

I have an application team that started receiving the following Exception:

11-Apr-2023 09:26:01.396 SEVERE [https-jsse-nio-0.0.0.0-11510-exec-19] 
org.apache.catalina.core.StandardHostValve.custom Exception Processing ErrorPa  
  ge[exceptionType=java.lang.Exception, location=/jsp/sendMessage.jsp]
 java.lang.NoSuchFieldError: EMPTY_CHAR_ARRAY
 at 
org.apache.catalina.core.ApplicationContext.getRequestDispatcher(ApplicationContext.java:459)
at 
org.apache.catalina.core.ApplicationContextFacade.getRequestDispatcher(ApplicationContextFacade.java:215)
at 
org.apache.catalina.core.StandardHostValve.custom(StandardHostValve.java:343)
at 
org.apache.catalina.core.StandardHostValve.throwable(StandardHostValve.java:302)

If did NOT do this with 9.0.70.

We know that it may be something that changed between 9.0.70 and 9.0.73, but we 
don't know.


The field org.apache.tomcat.util.buf.MessageBytes.EMPTY_CHAR_ARRAY was 
added.


It looks like you are trying to use JARs from different versions of 
Tomcat. You can sometimes get away with doing that. This isn't one of 
those times.


You need to fix the 9.0.73 install so it is using all the 9.0.73 JARs 
and none from earlier Tomcat versions.


Mark



So far searching the Google isn't giving us much information, so reaching out 
to the experts.

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.




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

Re: Is Microsoft's spring-cloud-azure-starter-active-directory for Spring Boot 3 / Spring 6 compatible with Tomcat 10?

[Mark Thomas]

On 13/04/2023 22:48, BRUNO MELLONI wrote:

After further research let me ask the question in a different way:


   *   Tomcat 10 is configured to do log4j2 logging.
   *   My log4j2 code works fine.
   *   Spring-cloud-azure-starter-active-directory seems to use logback and it 
is incompatible with my Tomcat 10 setup.

Given the above… what do I need to add to Tomcat 10 to make it handle apps that 
use logback for logging but still use my log4j2 Tomcat configuration for the 
actual logging?


Whatever the logback documentation says you need to add to route logging 
to log4j2.



I would swear that Tomcat had slf4j and other logging translation libraries 
built in…


Nope. That has never been the case.


but perhaps Tomcat 10 no longer does for some and requires adding some jars?


Tomcat's internal logging routes to java.util.logging - you can re-route 
that if required. Follow the directions to do that provided with your 
logging framework of choice.


Assuming you are still seeing the:

"Cannot cast 
ch.qos.logback.classic.servlet.LogbackServletContainerInitializer to 
jakarta.servlet.ServletContainerInitializer" error, I'll repeat my 
previous question:


Which version of which JAR is that ServletContainerInitializer coming from?

Mark




b.

From: Mark Thomas 
Sent: Tuesday, April 11, 2023 2:41 PM
To: users@tomcat.apache.org
Subject: Re: Is Microsoft's spring-cloud-azure-starter-active-directory for 
Spring Boot 3 / Spring 6 compatible with Tomcat 10?

On 11/04/2023 20: 28, BRUNO MELLONI wrote: > I was able to migrate applications to 
Spring Boot 3 / Spring 6 (standalone or running on Tomcat 10) so long as authentication 
was NOT through Azure AD. > > But when I tried to migrate applications
ZjQcmQRYFpfptBannerStart
CAUTION: This Message Is From an External Source
This message originated outside the Chickasaw Nation. Do not click links or 
open attachments unless you recognize the sender and know the content is safe!
 Report Suspicious  

   ‌
ZjQcmQRYFpfptBannerEnd

On 11/04/2023 20:28, BRUNO MELLONI wrote:


I was able to migrate applications to Spring Boot 3 / Spring 6 (standalone or 
running on Tomcat 10) so long as authentication was NOT through Azure AD.







But when I tried to migrate applications that used Microsoft's 
spring-cloud-azure-starter-active-directory for authentication of 2-step 
authenticated webapps (the preferred approach) I started to get this error 
during application deploy to Tomcat 10:







Cannot cast ch.qos.logback.classic.servlet.LogbackServletContainerInitializer 
to jakarta.servlet.ServletContainerInitializer











My suspicion is that Microsoft's latest implementation is not compatible with 
Tomcat's approach to support log4j logging (as far as I know the approach has 
been around since at least Tomcat 9).  But of course I could be wrong.   Has 
anybody had any success?  Was there any trick to migrating to Spring Boot 3 / 
Spring 6 / Tomcat 10 with 2-step authentication and authorization using Azure 
AD?















NOTE:  I did succeed with 2-step auth with Azure AD when I dropped the 
Microsoft spring-cloud-azure-starter-active-directory dependency and instead 
used the raw OAuth2 approach to connect to Azure AD.  The problem though is 
that roles defined in Azure are not coming through to the GrantedAuthorities of 
the SecurityContext or Principal.  I know I could extract the UPN from the 
Principal and then define the AD Groups in the on-premises AD instead of Azure 
AD, but that would require code changes and what is worse it would make me 
hostage to the availability of sysadmins that manage our on-premises AD... 
meaning weeks of delay for new AD groups.  It is a hack that I'd rather not use 
if Azure authorization can be made to work properly.







Any other advice will be welcome too.




No idea but some questions that might help.



Some sort of Java EE / Jakarta EE conflict?



A JAR present in the WAR that contains some of the Servlet API JARs?



Which version of which JAR is that ServletContainerInitializer coming from?



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

Re: Multiple entries

[Torsten Krah]

That has nothing to do with Tomcat, just autowire them by name and not by
type like the exception is telling you.

Kevin Huntly  schrieb am Fr., 14. Apr. 2023, 13:47:

> Hi Everyone,
>
> I can't remember if I posted this already or not (and I don't know how to
> check)... I'm getting the following message when I have more than one
>  value to obtain:
>
> tomcat config in context.xml
>  override="false" />
>  override="false" />
>  override="false" />
>
> And my Spring config:
>
>  jndi-name="java:comp/env/isTestSystem" />
>
>  "java:comp/env/webURL" />
>
>  jndi-name="java:comp/env/isResetAvailable" />
>
>
> I'm getting the following exception:
>
>
> Caused by:
> org.springframework.beans.factory.UnsatisfiedDependencyException: Error
> creating bean with name 'appConfig': Unsatisfied dependency expressed
> through field 'homePage'; nested exception is
> org.springframework.beans.factory.NoUniqueBeanDefinitionException: No
> qualifying bean of type 'java.lang.String' available: expected single
> matching bean but found 2: isTestSystem,webURL Anyone have any ideas?
> 
>
> Kevin Huntly
> Email: kmhun...@gmail.com
> Cell: 716/424-3311
> 
>
> -BEGIN GEEK CODE BLOCK-
> Version: 1.0
> GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
> W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
> PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
> G++ e(+) h--- r+++ y+++*
> --END GEEK CODE BLOCK--

AW: Tomcat needs an authenticator valve for OpenID/MSAL!

[Keil, Matthias (ORISA Software GmbH)]

Hello 


> -Ursprüngliche Nachricht-
> Von: Kevin Edward 
> Gesendet: Freitag, 7. April 2023 14:26
> An: users@tomcat.apache.org
> Betreff: Tomcat needs an authenticator valve for OpenID/MSAL!
> 
> Tomcat community,
> 
> We have been using keycloak tomcat valves for SAML, but now we are
> moving to OpenID.
> 
> Who in the tomcat community can create/support a tomcat authenticator
> valve using the MSAL library?
> 
> I have the example authentication servlet working for MSAL below. Seems it
> could be easily converted to a tomcat authenticator valve:
> 
> https://github.com/Azure-Samples/ms-identity-msal-java-
> samples/tree/main/3.%20Java%20Servlet%20Web%20App%20Tutorial/1-
> Authentication/sign-in
> 
> Thank you for any and all help!
> K
[>] 

Instead of using a valve, I have had good experiences with Open ID Connect and 
JASPIC.

Here is an example: 
https://tomcat.apache.org/tomcat-9.0-doc/config/jaspic.html#Philip_Green_II's_module_for_Google_OAuth_2
 

When using JASPIC you can use the tomcat mechanisms for authentication and 
authorization.

Greetings

Matthias 

Multiple entries

[Kevin Huntly]

Hi Everyone,

I can't remember if I posted this already or not (and I don't know how to
check)... I'm getting the following message when I have more than one
 value to obtain:

tomcat config in context.xml




And my Spring config:








I'm getting the following exception:


Caused by:
org.springframework.beans.factory.UnsatisfiedDependencyException: Error
creating bean with name 'appConfig': Unsatisfied dependency expressed
through field 'homePage'; nested exception is
org.springframework.beans.factory.NoUniqueBeanDefinitionException: No
qualifying bean of type 'java.lang.String' available: expected single
matching bean but found 2: isTestSystem,webURL Anyone have any ideas?


Kevin Huntly
Email: kmhun...@gmail.com
Cell: 716/424-3311


-BEGIN GEEK CODE BLOCK-
Version: 1.0
GCS/IT d+ s a C++ UL+++$ P+(++) L+++ E---
W+++ N+ o K(+) w--- O- M-- V-- PS+ PE Y(+)
PGP++(+++) t+ 5-- X-- R+ tv+ b++  DI++ D++
G++ e(+) h--- r+++ y+++*
--END GEEK CODE BLOCK--

Re: Tomcat 8.5.85 and above - Issue with file uploads

[Olaf Kock]

On 13.04.23 22:40, William L. Cunningham wrote:

Environment:  Windows 2019 Standard with latest JDK 17 and Apache Tomcat 8.5.87.

When trying to upload a file to the application running off Tomcat (custom 
software), we are getting the following error since 8.5.85 (works fine on 
8.5.84).

ERROR [2023-04-13 15:20:20]: 
com.company.dataimporter.servlet.FileUpload::doPost::85 Cannot delete 
C:\Program Files\Apache Software Foundation\Tomcat 
8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
java.lang.IllegalStateException: Cannot delete C:\Program Files\Apache Software 
Foundation\Tomcat 
8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
  at 
org.apache.tomcat.util.http.fileupload.disk.DiskFileItem.delete(DiskFileItem.java:428)
 ~[tomcat-coyote.jar:8.5.87]

This same procedure works perfectly fine in 8.5.84.  It was something 
introduced with 8.5.85.  It also works fine on a Linux hosted version (Centos) 
for 8.5.84 and above.  So it appears to be Windows centric.

When I watch the procedure in the Catalina\localhost\company folder on 8.5.84, 
I see the tmp file generated and then immediately deleted (it's a small 
upload).  On 8.5.85 and above, it's locked and can't be deleted.  Thus causing 
the error.



You should not install Tomcat in "C:\Program Files", or at least not run 
it there (e.g. run it with CATALINA_BASE != CATALINA_HOME): Windows 
protects the content of "C:\Program Files\*" in some ways that I can't 
detail - it might very well interfere in the way that you describe. 
Maybe you had installed/run it from another directory earlier, and that 
was changed with the upgrade?


Olaf


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

Re: Java Heap Space Error

[Olaf Kock]

On 14.04.23 04:55, pratik.kulka...@shell.com.INVALID wrote:

Hi All,

Thanks for your quick suggestions.

As Olaf suggested, I tried to set the same values to Xms and Xmx; the 
application immediately crashes after Tomcat restart and I am not able to 
access it. I tried it with different values, but the result is the same. 
Regarding the memory leak, let me check on how to monitor an Oracle Apex 
application running on Tomcat, since this is something I have never done before.


Here are a few ideas for this paragraph:

As your application can't run with -Xms set to the limit, you have 
proven that your computer does not have enough memory to allocate for 
your requirements (maybe due to other applications taking it, maybe it's 
just due to low RAM to begin with. I'm not sure why this would surface 
after upgrading Tomcat, but maybe your settings are different in other 
aspects as well, or other applications now take more memory.


(I'd recommend Xms==Xmx for all Java Server applications, to get the 
OOME quicker, rather than Sunday night at 3am, at random)


If you just connect jconsole, you should be able to see a characteristic 
sawtooth curve of memory, going up, hinting at - not necessarily proving 
- memory leaks (it might also just indicate legitimate memory usage - 
it's a quick check: If the sawtooth is horizontal, you have a strong 
indicator that there's no memory leak)


Typically, I don't really concentrate on the actual stacktrace of the 
OOME, as this is just what happened to require the last bit of memory, 
after everything else has been consumed. This *might* be the guilty 
code, but it might also just be a false positive. To me, OOME 
stacktraces have more often misled me than they pointed to the problem. 
A heapdump, with an indicator of what actually consumes your memory (and 
then judging if it's legit or not) helps a lot more IMHO.


Olaf


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