[keycloak-dev] Do we really want to keep support for Wildfly 8.2.0.Final

Marko Strukelj mstrukel at redhat.com
Mon May 18 09:46:50 EDT 2015


In recent weeks I upgraded Wildfly version we use for server distro to 9.0.0.CR1 in order to be up to date with latest subsystem APIs. That was accompanied by server / adapter subsystem split, and code cleanup that fixed deprecated uses of Wildfly subsystems APIs. It also resulted in dropped support for EAP6 within keycloak-wildfly-adapter-susbsystem.

I've been working on putting EAP6 support into keycloak-as7-subsystem, and that seems to work fine.

We thus have adapter support for WF9, and EAP7 via wildfly-adapter-subsystem, and adapter support for AS7, and EAP6 via as7-subsystem.

That leaves out WF8. Since it uses undertow, it makes no sense to try put it into as7-subsystem, and since it uses APIs deprecated in WF9 it makes no sense to put it into wildfly-adapter-subsystem as that would require again messing up the just-cleaned-up subsystems code.
  
There's another issue that's specific to WF8 - org.apache.httpcomponents slot=4.3. That complicates the modules build, and the examples build. Manually testing AS7, EAP6, WF9 using unconfigured-demo I was constantly bumping into mismatches between jboss-deployment-structure.xml in demos and the modules in the server.

It makes no sense to bundle org.apache.httpcomponents slot=4.3 with WF9, but we have to bundle them with WF8. Current build does not solve this issue yet. I have a solution in the works, but maybe we want to decide not to support WF 8 at all. For all practical purposes WF 9.0.0.CR1 is equivalent and better than 8.2.0.Final so I see no reason why people couldn't upgrade other then maybe emotional attachment to .Final in the version.

What do the rest of you think? Am I missing something?


More information about the keycloak-dev mailing list