Problems excluding the included javax.servlet.api with WildFly 26

[Still Learning]

We want to use a different version of the javax.servlet.api than what is included in the WildFly modules directory.   It seems javax.servlet.2.0.0.Final is being loaded even though in our jboss-deployment-structure file we have excluded it.  We have a custom module with a later version and when we try to run the app we get the Failed to link javax/servlet/ServletContext error.   Basically saying that the 2.0.0 version was already loaded when the app attempted to load the 4.0 version we want to use.

I started blindly adding to the exclusions but it seems no matter how many I add I still get the same error.  Are there subsystems that must be excluded in order to use our version of javax.servlet.api in addition to excluding the modules?

Thanks  

[James Perkins]

Is there a reason you want to use a different version of the Jakarta Servlet API? Undertow implements the Servlet API and requires a specific version. It's not a trivial task to attempt to change the Servlet API module.

[Scott Marlow]

> Does anyone have any suggestions on how to resolve this issue?

No as the Jakarta EE deployer ensures that your application deployment (classloader) has the needed Jakarta EE Specification APIs added, which would be the jboss-servlet-api_4.0_spec-2.0.0.Final.jar included with WildFly 26.  However since jboss-servlet-api_4.0_spec-2.0.0.Final.jar is binary compatible with Servlet 4.0, there is not reason that I know of to use a different Servlet jar.  Unless your hitting a problem because WildFly 26 is using a fork of the Servlet 4.0 SPEC API source.  If so, please let us know so we can understand why your trying to use a different Servlet SPEC API jar.

Scott

[Still Learning]

James,

  We are in the process of upgrading some old jars on the project and an older version of WildFly.   We were trying to get around the javax and jarkarta collision on some jars. We are in between deciding to go fully jarkarta or remaining javax.  

[James Perkins]

Unfortunately it's pretty much an all in or all out. You cannot mix the two.

One option is to use WildFly 28 and use the deployment transformer feature pack. What this does is changes the byte code at deployment time to convert the javax->jakarta namespaces.