[dmichulke]

I use a similar setup from time to time and one of my main problems with this is XMHell - you set up everything in XML and whenever something doesn't work, it's hard to find help because you'll get a stack trace instead of "WARNING: <xmlpath> seems to be incorrect" or "Module X: When using feature Y with setting Z, you also need to define A, B and C"

A recent example is trying to make Hibernate work via postgis and postgresql as a datasource in Wildfly. We weren't able to solve it, we could only work around it.

Finally, if you need some behavior off the beaten path, you'll have to use lots of annotated Java which makes it easy if you know all this but it's hard to read a Java file with 10 annotations for classes and methods, simply because you don't know what happens when.

To summarize, it's an ok solution if you have a Java guy with lots of experience in all this (luckily we had one). Otherwise you gonna have to learn a lot (as in by heart) because you can't really reason about XML and annotations (as you could, e.g., when composing services in Clojure).

[hackercomplex]

As you point out there's definitely a learning curve with this tech, however there's also a learning curve with rolling your own versions of many of it's capabilities which is the alternative. I also personally find XML configuration files distasteful, but luckily I found that the default configuration was good enough for me to stand up a clustered "HA" environment with all the bells and whistles.

There are projects out there such as Torquebox for JRuby and Immutant for Clojure which attempt to wrap some of this configuration in a DSL which I think is really convenient.

It is true though that if you want to extend Wildfly you need to create a Wildfly module which can mean writing Java code. I look at this as being similar to how if you want to extend NGINX you have to be prepared to write your configuration in LUA or C. Unfortunately the JBoss community isn't as well documented as NGINX is right now, so realistically there is some pain.

Since my application didn't need to have Wildfly manage database thread pools on it's behalf I didn't feel the specific pain point that you mention.

Over the long term, when thinking about scale I enjoy knowing that there are companies like Redhat out there who provide support for this technology, but I don't anticipate ever needing to engage them. With this tech configuration is always the hard part but once it's up and running it's performance characteristics are predictable and the Undertow web server is in the top 5 on the latest benchmarks: https://www.techempower.com/benchmarks/#section=data-r11&hw=...