date:20240614

RE: Changes between Tomcat 9.0.86 and 9.0.88?

2024-06-14 Thread Mcalexander, Jon J.

Thanks Chris!

So, was this removal not noted in the Release Notes? (I’m not seeing it.)

Thanks,

From: Christopher Schultz 
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.(AESKeySource.java:43)

> at 
> com.wellsfargo.jsk.core.components.AESResourceKeySource.init(AESResourceKeySource.java:36)

> at 
> com.wellsfargo.jsk.core.components.AESResourceKeySource.(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()

> at 
> com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration$$EnhancerBySpringCGLIB$$6621bc2f$$FastClassBySpringCGLIB$$964773e5.invoke()

> 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()

> 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$



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 mailto:n82...@gmail.com>>

> Sent: Thursday, June 13, 2024 1:13 PM

> To: Tomcat Users List 
> 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. > 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. 
>> 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.

Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups

2024-06-14 Thread Mark Thomas

Just to follow up on this.

I tripped over a related issue today running the Tomcat unit tests for
9.0.x. Being able to reproduce it gave me a chance to dig further and
come up with a better fix. These interfaces are marked as "point to
point" interfaces which Java can see so we can skip them. I've updated
the unlock code and the fix will be in the July release round.

Mark

On 26/02/2024 15:59, Michał Szymborski wrote:
Thank you, that clears things up. I did not think about implication of
using wildcard. I will try to use explicit addresses from now on. You
learn something new every day!

Cheers,
Michał

On 26.02.2024 09:48, Mark Thomas wrote:

On 25/02/2024 18:18, Michał Szymborski wrote:

On quick inspection the acceptor thread
(https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/Acceptor.java#L128) was listening on [/[0:0:0:0:0:0:0:0]:39033]
, which was correctly picked up at first, but then this local address
got transformed:

0.0.0.0 is shorthand for "all configured IP address". Tomcat can't use
that address to establish a connection to the Acceptor thread so it
has to try and deduce a valid IP local address from the network
configuration information exposed through the Java APIs.

https://github.com/apache/tomcat/blob/10.1.x/java/org/apache/tomcat/util/net/AbstractEndpoint.java#L1164

It started picking up interfaces to use, and it stopped at the first
non-loopback non-link local address, which also happens to be some
sort of a bridge network for one of my VMs. I don't quite know why
there is no routing set up, but this interface should not have been
picked in the first place.

It is a local IP address so as far as Tomcat can see it should be
valid to connect to the Acceptor.

I'll take a look at how it works on my work laptop with MacOs, but
I'd wager a guess that some corporate VPNs have interfaces which have
messed up routing as well. Can't tell if it's a bug or a feature, but
it sure is unexpected. Making this timeout for acceptor shutdown
configurable would be one sort of band-aid.

It is configurable. socket.unlockTimeout. Documented default is 250ms
although looking at the code it appears there is a minimum of 2000ms -
need to see why that is.

Configuring a specific address (even 127.0.0.1) for the Connector
would also address this.

Mark

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

Re: Changes between Tomcat 9.0.86 and 9.0.88?

2024-06-14 Thread Rémy Maucherat

On Thu, Jun 13, 2024 at 11:30 PM Christopher Schultz
 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.(AESKeySource.java:43)
> > at 
> > com.wellsfargo.jsk.core.components.AESResourceKeySource.init(AESResourceKeySource.java:36)
> > at 
> > com.wellsfargo.jsk.core.components.AESResourceKeySource.(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()
> > at 
> > com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration$$EnhancerBySpringCGLIB$$6621bc2f$$FastClassBySpringCGLIB$$964773e5.invoke()
> > 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()
> > 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 
> > Sent: Thursday, June 13, 2024 1:13 PM
> > To: Tomcat Users List 
> > Subject: Re: Changes between Tomcat 9.0.86 and 9.0.88?
> >
> >> On Jun 13, 2024, at 12: 45, Mcalexander, Jon J.  >> 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. 
> >> 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$

RE: Changes between Tomcat 9.0.86 and 9.0.88?

2024-06-14 Thread Mcalexander, Jon J.

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 
Sent: Friday, June 14, 2024 4:28 PM
To: Tomcat Users List 
Subject: Re: Changes between Tomcat 9.0.86 and 9.0.88?

On Thu, Jun 13, 2024 at 11: 30 PM Christopher Schultz  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

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.(AESKeySource.java:43)

> > at 
> > com.wellsfargo.jsk.core.components.AESResourceKeySource.init(AESResourceKeySource.java:36)

> > at 
> > com.wellsfargo.jsk.core.components.AESResourceKeySource.(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()

> > at 
> > com.wellsfargo.branch.digitalbranchservices.configuration.BaseRepositoryConfiguration$$EnhancerBySpringCGLIB$$6621bc2f$$FastClassBySpringCGLIB$$964773e5.invoke()

> > 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()

> > 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$

>

> 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 mailto:n82...@gmail.com>>

> > Sent: Thursday, June 13, 2024 1:13 PM

> > To: Tomcat Users List 
> > 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.  >> wellsfargo. com. INVALID> wrote: > > I have an application team that 
> >> started having

RE: Changes between Tomcat 9.0.86 and 9.0.88?

Re: A curious case of Tomcat 10.1.x NIO(1) acceptor not stopping clearly on some setups

Re: Changes between Tomcat 9.0.86 and 9.0.88?

RE: Changes between Tomcat 9.0.86 and 9.0.88?

4 matches

Site Navigation

Mail list logo

Footer information