Runtime exception upon jetty restart on load

[Francesco Malvezzi]

On 27/03/24 16:06, Cantor, Scott wrote:
> It's impossible for this to be "transitory", it's an issue with Java's restrictions in newer versions and it either happens or it doesn’t, but the issue is/was inside the Warning interceptor, so it only happens when that runs.

I agree with you, but I am just describing what's happening.

> 
> Having said that, we know it was a Spring reflection bug and it's long fixed. I have not seen the issue since, and I have no idea how somebody would encounter it now. We have a canary unit test in place so that we'd know if Spring had the issue ever again, and they don't.
> 
> The original closed bug [1]
> The new one somebody filed [2]
> 
> I use that flow, and it hasn't ever failed like this in recent memory since the Spring bug was fixed, so I have no doubt that it's environmental/corruption of some sort. But at this point, "try 5.x" is the only practical advice I have, and that likely won't help since the latest report about it was on 5.0.
> 
> If a member runs into it, I'll do more digging with them, there's probably a localized "habit" that's incorrect in some way and must be causing it.

Your detailed explanations helped me a lot to make a step forward.

I had a couple of outdated jars in the classpath from the groovy-3.* 
scripting language distribution. I updated them and now the Uncaught 
runtime exception arises just once per-restart (not as before at any 
authentication, actually blocking the service).

I would wait for the classes to start back (we are on easter holidays 
and the workload is low) to confirm the issue is solved, but I'm quite 
confident now.

The 'environmental' issue was the rogue jar and the 'localized "habit"' 
was drifting from the main path of using javascript as scripting 
language, which is something I have to think seriously about,

Thank you so much,

Francesco