[JENKINS-26677] Avoid using ServletException from SlaveComputer since it can break calls to SlaveComputer.getChannelToMaster

[jglick]

A recently reported case:

java.lang.NoClassDefFoundError: javax/servlet/ServletException
	at hudson.util.ProcessTree.get(ProcessTree.java:399)

Untested, since I am not sure how to reproduce the reporter’s situation. At least it cannot hurt. Similar to #2551.

See JENKINS-26677.

Proposed changelog entries

• Trying to avoid a NoClassDefFoundError: javax/servlet/ServletException under some conditions using an agent.

[jvz]

Fix makes sense. Any way to verify this doesn't get broken again? Not exactly sure on how unit testable this is.

[jglick]

Any way to verify this doesn't get broken again?

That is exactly what JENKINS-26677 proposes. As I mentioned on the dev list, there have been some preliminary efforts here, but no follow-through. See JENKINS-38372. This might need a Telemetry in general, though I think Servlet API classes are clear blacklist candidates.

[jschneider]

Could you check the build again?

[jglick]

see #3799

[amuniz]

@jglick

I'm hitting this bug even after this fix. Based on my local checks, it happens until a channel.preloadJar(ServletException.class) call is done so the servlet container jar travels to the remoting jar cache. After that, the problem is hidden.

This is consistently reproducible for me:

1. Create a permanent agent
2. Clean the jar cache (usually under $HOME/.jenkins or agent root dir jarCache) in the agent machine
3. Go to the agent script console (/computer/[agent-name]/script)
4. Run hudson.util.ProcessTree.get() or Functions.isWindows() or ... (whatever using servlet classes)

[jglick]

• Go to the agent script console (/computer/[agent-name]/script)
• Run hudson.util.ProcessTree.get() or Functions.isWindows() or ... (whatever using servlet classes)

Well, yes, so you should not do that! Until there is an automated system in place to ensure that classes useful in a remote context do not link against Servlet (for which see JENKINS-26677), we need to manually ensure that no classes used in a typical scenario violate the rule. So, certainly not Functions. Not sure offhand why ProcessTree would be a problem; the JVM’s error messages do not pinpoint the actual referring class, only the class initially being resolved in a chain which wound up triggering the linkage error.