On Thu, Jun 13, 2024 at 11:30 PM Christopher Schultz <ch...@christopherschultz.net> wrote: > > 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://github.com/apache/tomcat/commit/1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce > > 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.
This removal should probably not have happened IMO, the whole class was marked deprecated right after that commit. It looks like an old commit (from two years before) that Mark had lying around, that got pushed right before the rebase. We should consider adding the methods back in 9.0 (and maybe 10.1). Rémy > -chris > > > From: Chuck Caldarale <n82...@gmail.com> > > Sent: Thursday, June 13, 2024 1:13 PM > > To: Tomcat Users List <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>> > >> 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$> > > > > > > > > > > > > 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 > 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
