cloudfoundry
build(deps): bump versions.tomcatCargoVersion from 9.0.91 to 9.0.93
Bumps versions.tomcatCargoVersion from 9.0.91 to 9.0.93.
Updates org.apache.tomcat.embed:tomcat-embed-el from 9.0.91 to 9.0.93
Updates org.apache.tomcat.embed:tomcat-embed-core from 9.0.91 to 9.0.93
Updates org.apache.tomcat.embed:tomcat-embed-jasper from 9.0.91 to 9.0.93
Updates org.apache.tomcat:tomcat-jdbc from 9.0.91 to 9.0.93
Most Recent Ignore Conditions Applied to This Pull Request
| Dependency Name | Ignore Conditions |
|---|---|
| org.apache.tomcat.embed:tomcat-embed-core | [>= 10.a, < 11] |
| org.apache.tomcat.embed:tomcat-embed-el | [>= 10.a, < 11] |
| org.apache.tomcat.embed:tomcat-embed-jasper | [>= 10.a, < 11] |
| org.apache.tomcat:tomcat-jdbc | [>= 10.a, < 11] |
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
-
@dependabot rebasewill rebase this PR -
@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it -
@dependabot mergewill merge this PR after your CI passes on it -
@dependabot squash and mergewill squash and merge this PR after your CI passes on it -
@dependabot cancel mergewill cancel a previously requested merge and block automerging -
@dependabot reopenwill reopen this PR if it is closed -
@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually -
@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency -
@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) -
@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
![dependabot[bot] avatar](https://avatars.githubusercontent.com/in/29110?v=4 "Published by a pub.dev verified publisher"){kind=small}
Marking as [DoNotMerge] because this bump caused failure in uaa-acceptance-gcp/jobs/test-cf-deployment-integration and uaa-acceptance-gcp/jobs/deploy-cf as follows:
Task 2658 | 23:47:03 | L executing post-start: uaa/00aac8c8-dc57-44cf-abf8-b98f201151e6 (0) (canary) (00:11:02)
L Error: Action Failed get_task: Task 9e36113d-082c-4b6e-7309-0189453b5c90 result: 1 of 2 post-start scripts failed. Failed Jobs: uaa. Successful Jobs: bosh-dns.
Task 2658 | 23:57:04 | Error: Action Failed get_task: Task 9e36113d-082c-4b6e-7309-0189453b5c90 result: 1 of 2 post-start scripts failed. Failed Jobs: uaa. Successful Jobs: bosh-dns.
uaa.log contained error messages as follows:
[2024-08-07T20:42:57.275063Z] uaa - 11 [main] - [,] .... ERROR — DispatcherServlet: Context initialization failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.cloudfoundry.identity.uaa.security.web.SecurityFilterChainPostProcessor#0' defined in ServletContext resource [/WEB-INF/spring-servlet.xml]: Cannot resolve reference to bean 'identityZoneResolvingFilter' while setting bean property 'additionalFilters' with key [TypedStringValue: value [{T(org.cloudfoundry.identity.uaa.security.web.SecurityFilterChainPostProcessor.FilterPosition).position(6)}](https://jira.eng.vmware.com/browse/TPCF-25522#{T(org.cloudfoundry.identity.uaa.security.web.SecurityFilterChainPostProcessor.FilterPosition).position(6)}), target type [null]]; nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'identityZoneResolvingFilter' defined in ServletContext resource [/WEB-INF/spring-servlet.xml]: Unsatisfied dep
...
Caused by: java.sql.SQLSyntaxErrorException: (conn=23096) SELECT command denied to user 'uaa'@'10.0.1.3' for table 'user_variables_by_thread'
at org.mariadb.jdbc.internal.util.exceptions.ExceptionFactory.createException(ExceptionFactory.java:62) ~[mariadb-java-client-2.7.12.jar:?]
...
at org.flywaydb.core.internal.schemahistory.SchemaHistoryFactory.prepareSchemas(SchemaHistoryFactory.java:114) ~[fl
yway-core-7.15.0.jar:?]
at org.flywaydb.core.Flyway.execute(Flyway.java:548) ~[flyway-core-7.15.0.jar:?]
at org.flywaydb.core.Flyway.repair(Flyway.java:440) ~[flyway-core-7.15.0.jar:?]
at org.cloudfoundry.identity.uaa.db.beans.FlywayConfiguration$FlywayConfigurationWithMigration.flyway(FlywayConfigu
ration.java:65) ~[cloudfoundry-identity-server-77.15.0.jar:?]
at org.cloudfoundry.identity.uaa.db.beans.FlywayConfiguration$FlywayConfigurationWithMigration$$EnhancerBySpringCGL
IB$$6a4607f6.CGLIB$flyway$0(<generated>) ~[cloudfoundry-identity-server-77.15.0.jar:?]
For this reason, the same bump was reverted in 889890b77ef5b94333788658cf17a5aed52dee22. Will need to figure out the cause of the failure before being able to bump this.
More analysis
As seen in the following cause exception, tomcat-jdbc code is in the call stack, and there was some change around that code in Tomcat 9.0.92. (See https://tomcat.apache.org/tomcat-9.0-doc/changelog.html.)
Caused by: java.sql.SQLException: SELECT command denied to user 'uaa'@'10.0.1.1' for table 'user_variables_by_thread'
at org.mariadb.jdbc.internal.protocol.AbstractQueryProtocol.readErrorPacket(AbstractQueryProtocol.java:1701) ~[mariadb-java-client-2.7.12.jar:?]
...
at java.lang.reflect.Method.invoke(Method.java:569) ~[?:?]
at org.apache.tomcat.jdbc.pool.interceptor.AbstractQueryReport$StatementProxy.invoke(AbstractQueryReport.java:214) ~[tomcat-jdbc-9.0.93.jar:?]
at jdk.proxy4.$Proxy170.executeQuery(Unknown Source) ~[?:?]
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
at ...
jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:569) ~[?:?]
at org.apache.tomcat.jdbc.pool.StatementFacade$StatementProxy.invoke(StatementFacade.java:130) ~[tomcat-jdbc-9.0.93.jar:?]
at jdk.proxy4.$Proxy170.executeQuery(Unknown Source) ~[?:?]
at org.flywaydb.core.internal.jdbc.JdbcTemplate.queryForStringList(JdbcTemplate.java:116) ~[flyway-core-7.15.0.jar:?]
While not being able to relate the issue to the tomcat code change directly, it is likely that the tomcat code change is cause of the issue we are seeing here. I was not able to reproduce the problem locally, so it is hard to narrow it down to the exact cause of the issue. At this point, I think that we should wait for next Tomcat release to see if it is fixed then. (See https://nightlies.apache.org/tomcat/tomcat-9.0.x/docs/changelog.html.)
Suggested plan
Ignore tomcat bump till next patch version is available, i.e. stay with 9.0.91 till 9.0.94 is available. I was concerned about having different tomcat version for uaa-release and uaa. The former affects jar file versions in tomcat/lib while the later affects the jar files versions in tomcat/webapps/ROOT/WEB-INF/lib. However, now I am confident that it is OK as the jars under webapps/.../lib/ are the ones loaded for UAA app. (See https://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.html.) Also, our pipeline is currently passing with the different versions of Tomcat in uaa-release and uaa.