Hi, But be aware that's a generally bad idea to rely on implementation details of the underlying servlet container in application code.
Also java has native base64 since when? Java 8?! Just use that one. Mfg Thomas Am 15. Juni 2024 00:41:28 MESZ schrieb "Mcalexander, Jon J." <jonmcalexan...@wellsfargo.com.INVALID>: >Hi Rémy, > >So, is this something that will be done? If so, I can let the app team know >that even though they should recode their app, that the removed method may get >returned in a future release. > >Thanks, > >From: Rémy Maucherat <r...@apache.org> >Sent: Friday, June 14, 2024 4:28 PM >To: Tomcat Users List <users@tomcat.apache.org> >Subject: Re: Changes between Tomcat 9.0.86 and 9.0.88? > >On Thu, Jun 13, 2024 at 11: 30 PM Christopher Schultz <chris@ >christopherschultz. net> wrote: > > Jon, > > On 6/13/24 14: 27, Mcalexander, >Jon J. wrote: > > Thanks Chuck! Here is the full stack-trace > > > > > > >On Thu, Jun 13, 2024 at 11:30 PM Christopher Schultz > ><ch...@christopherschultz.net<mailto: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://urldefense.com/v3/__https://github.com/apache/tomcat/commit/1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce__;!!F9svGWnIaVPGSwU!rbtegXXK_wEiS3lbaUFrswVnku9t0kbNiERW7x30S-gAnbIHfXHvBLQxIITqaBrQVgFq1QCKO3LgekygGL-S$<https://urldefense.com/v3/__https:/github.com/apache/tomcat/commit/1a2f722e405ec17c5dab5fac43ae2fe63eb8fbce__;!!F9svGWnIaVPGSwU!rbtegXXK_wEiS3lbaUFrswVnku9t0kbNiERW7x30S-gAnbIHfXHvBLQxIITqaBrQVgFq1QCKO3LgekygGL-S$> > >> > >> 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<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> > >> > > > >--------------------------------------------------------------------- > >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> > > -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
