Thanks Chris! So, was this removal not noted in the Release Notes? (I’m not seeing it.)
Thanks, From: Christopher Schultz <ch...@christopherschultz.net> Sent: Thursday, June 13, 2024 4:30 PM To: users@tomcat.apache.org Subject: Re: Changes between Tomcat 9.0.86 and 9.0.88? Jon, On 6/13/24 14: 27, Mcalexander, Jon J. wrote: > Thanks Chuck! Here is the full stack-trace > > Jun 11, 2024 3: 21: 28 PM org. apache. catalina. startup. HostConfig deployDirectory > SEVERE: Error deploying web application directory Jon, On 6/13/24 14:27, Mcalexander, Jon J. wrote: > Thanks Chuck! Here is the full stack-trace > > Jun 11, 2024 3:21:28 PM org.apache.catalina.startup.HostConfig deployDirectory > SEVERE: Error deploying web application directory > [/prod/app/bankr/ist_bankr_4.0_a/webapps/digitalbranchservices] > java.lang.IllegalStateException: Error starting child > [blabity blah blah blah] > > Caused by: java.lang.NoSuchMethodError: > org.apache.tomcat.util.codec.binary.Base64.decodeBase64([B)[B > at > com.wellsfargo.jsk.core.components.AESKeySource.<init>(AESKeySource.java:43) > at > com.wellsfargo.jsk.core.components.AESResourceKeySource.init(AESResourceKeySource.java:36) > at > com.wellsfargo.jsk.core.components.AESResourceKeySource.<init>(AESResourceKeySource.java:21) > at > com.wellsfargo.jsk.core.utils.DecrypterUtil.getValue(DecrypterUtil.java:68) > at > com.wellsfargo.jsk.core.utils.DecrypterUtil.getValue(DecrypterUtil.java:62) > at > com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration.dataSource(BaseRepositoryConfiguration.java:172) > at > com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration$$EnhancerBySpringCGLIB$$6621bc2f.CGLIB$dataSource$0(<generated>) > at > com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration$$EnhancerBySpringCGLIB$$6621bc2f$$FastClassBySpringCGLIB$$964773e5.invoke(<generated>) > at > org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) > at > org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:331) > at > com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration$$EnhancerBySpringCGLIB$$6621bc2f.dataSource(<generated>) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:154) > ... 146 more Here is the commit that removed that code: https://urldefense.com/v3/__https://github.com/apache/tomcat/commit/1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce__;!!F9svGWnIaVPGSwU!op8ZX-cha_RpwTi7rHCl6ujPEi72qsbKDhlYQmzJEZCA1bNfH2TDHv9ZdMcYpN7gOMD2Liw-1xI1D32VIu_5LieTzj--HELh$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/commit/1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce__;!!F9svGWnIaVPGSwU!op8ZX-cha_RpwTi7rHCl6ujPEi72qsbKDhlYQmzJEZCA1bNfH2TDHv9ZdMcYpN7gOMD2Liw-1xI1D32VIu_5LieTzj--HELh$> Honestly, you should not be using those internal Tomcat APIs because (surprise!) they can change at any time. I would recommend consuming commons-codec directly as a dependency and you won't get surprises like this in the future. As a quick workaraound, you might be able to grab tomcat-util.jar from 9.0.86 and use that with your 9.0.88 install. It could melt your whole data center though, so be careful. That's a really impressive stack trace, I have to admit. I'm surprised you didn't get a StackOverflowError while it was being generated. -chris > From: Chuck Caldarale <n82...@gmail.com<mailto:n82...@gmail.com>> > Sent: Thursday, June 13, 2024 1:13 PM > To: Tomcat Users List > <users@tomcat.apache.org<mailto:users@tomcat.apache.org>> > Subject: Re: Changes between Tomcat 9.0.86 and 9.0.88? > >> On Jun 13, 2024, at 12: 45, Mcalexander, Jon J. <jonmcalexander@ wellsfargo. >> com. INVALID> wrote: > > I have an application team that started having >> problems with their application when they were updgraded from 9. 0. 86 to 9. >> 0. 88 > > > > >> On Jun 13, 2024, at 12:45, Mcalexander, Jon J. >> <jonmcalexan...@wellsfargo.com.INVALID<mailto:jonmcalexan...@wellsfargo.com.INVALID<mailto:jonmcalexan...@wellsfargo.com.INVALID%3cmailto:jonmcalexan...@wellsfargo.com.INVALID>>> >> wrote: > >> > >> I have an application team that started having problems with their >> application when they were updgraded from 9.0.86 to 9.0.88 version of >> Tomcat. The base cause of their stack-trace is: > >> > >> java.lang.NoSuchMethodError: >> org.apache.tomcat.util.codec.binary.Base64.decodeBase64 > >> > >> Was there a changes to the api since 9.0.86? I know that according to this >> link, base64 is deprecated? > >> > >> https://urldefense.com/v3/__https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/util/codec/binary/Base64.html__;!!F9svGWnIaVPGSwU!ucNLBYMrFWz_uWnMSNO6HRD_ofh0Q5kzQWdzcCVAF_cKeT7s3MzygchiD4Qwr4Np9soNKsBcEtrC_YA3-ZYDZg$<https://urldefense.com/v3/__https:/tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/util/codec/binary/Base64.html__;!!F9svGWnIaVPGSwU!ucNLBYMrFWz_uWnMSNO6HRD_ofh0Q5kzQWdzcCVAF_cKeT7s3MzygchiD4Qwr4Np9soNKsBcEtrC_YA3-ZYDZg$><https://urldefense.com/v3/__https:/tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/util/codec/binary/Base64.html__;!!F9svGWnIaVPGSwU!ucNLBYMrFWz_uWnMSNO6HRD_ofh0Q5kzQWdzcCVAF_cKeT7s3MzygchiD4Qwr4Np9soNKsBcEtrC_YA3-ZYDZg$%3chttps:/urldefense.com/v3/__https:/tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/util/codec/binary/Base64.html__;!!F9svGWnIaVPGSwU!ucNLBYMrFWz_uWnMSNO6HRD_ofh0Q5kzQWdzcCVAF_cKeT7s3MzygchiD4Qwr4Np9soNKsBcEtrC_YA3-ZYDZg$%3e%3e> ><https://urldefense.com/v3/__https:/tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/util/codec/binary/Base64.html__;!!F9svGWnIaVPGSwU!ucNLBYMrFWz_uWnMSNO6HRD_ofh0Q5kzQWdzcCVAF_cKeT7s3MzygchiD4Qwr4Np9soNKsBcEtrC_YA3-ZYDZg$%3chttps:/urldefense.com/v3/__https:/tomcat.apache.org/tomcat-9.0-doc/api/org/apache/tomcat/util/codec/binary/Base64.html__;!!F9svGWnIaVPGSwU!ucNLBYMrFWz_uWnMSNO6HRD_ofh0Q5kzQWdzcCVAF_cKeT7s3MzygchiD4Qwr4Np9soNKsBcEtrC_YA3-ZYDZg$%3e%3e> > > > > > One of the decodeBase64() methods was removed due to apparent non-use: > > > > public static byte[] decodeBase64(final byte[] base64Data) { > > return decodeBase64(base64Data, 0, base64Data.length); > > } > > > > Two decodeBase64() methods remain: > > > > public static byte[] decodeBase64( > > final byte[] base64Data, final int off, final int len) > > > > public static byte[] decodeBase64(final String base64String) > > > > Without the full stack trace, it’s not possible to see where the call to the > removed method comes from, but hopefully you could recode the caller to add > the offset and length parameters. > > > > - Chuck > > > > > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org<mailto:users-unsubscr...@tomcat.apache.org> For additional commands, e-mail: users-h...@tomcat.apache.org<mailto:users-h...@tomcat.apache.org>
