MVC on Wildfly
A new hope for Server-Side-Frontends
MVC 1.0 has been one of my most anticipated features from Java-EE 8. The spec describes a new frontend framework that is designed around the request/response-pattern of HTTP, instead of trying to hide it from you like JSF does. There are quiet a few frameworks around that follow this approach, like Spring MVC, the Play Framework or Struts. MVC 1.0 comes as an extension to JAX-RS: it uses existing annotations like @Path, the HTTP-Verbs @GET, @POST etc. and @FormParam or @BeanParam for binding, which gives it a gentle learning curve if you’re already familiar with JAX-RS. From there on, you can use pretty much any template engines known to the Java ecosystem for rendering your views (there is even one for React). To my disappointment, Oracle decided that the spec will not be part of Java-EE 8, but will be released as a spec on its own and leave it to the vendors to decide whether to implement it in their products.
Things got a little quiet around MVC since then. There is a reference implementation called „Ozark“ that only worked on Jersey/Glassfish. Its Website looks a little out of date and most of the development is taking place in a google-group, which makes the project look a little abandoned but it’s definitely not. Ozark works really well, but until lately using it on Wildfly pretty much came down to ripping the RestEasy-based JAX-RS Subsystem out and shipping Jersey with your application (yeah, it works just as smooth at it sounds…). Most of the blog posts and even the official website still describe this approach: https://www.mvc-spec.org/ozark/docs/install_wildfly.html
Lately, quiet a lot of effort went into making Ozark independent from the JAX-RS implementation. Jersey specific features were ported to CDI instead and the project was split up into a core and modules for Jersey and RestEasy. That made integrating MVC really simple for Wildfly users. All you need to do is add some dependencies for the MVC-Spec and the Ozark-RestEasy module — no more messing with Wildfly modules or Jersey servlets.
These are the dependencies that you need:
<dependency>
<groupId>javax.mvc</groupId>
<artifactId>javax.mvc-api</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.mvc-spec.ozark</groupId>
<artifactId>ozark-core</artifactId>
<version>1.0.0-m03-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>org.mvc-spec.ozark</groupId>
<artifactId>ozark-resteasy</artifactId>
<version>1.0.0-m03-SNAPSHOT</version>
</dependency>I wanted to take things a little further and see if MVC could be integrated with Wildly on a level similar to the other Java-EE frameworks: just add the javax.mvc-API as a provided dependency to your project and let application server take care of the implementation details. So, here’s my shot on a Wildfly-Subsystem for MVC 1.0 based on ozark:
http://github.com/gtudan/wildfly-ozark
It’s basically a zip file that you extract to your Wildfly 10 base directory. After a few lines of config to enable the extension (please see the readme), the new subsystem will detect the MVC @Controller-Annotation in a project and add the required dependencies to the project. All that’s left to do on the application side is adding the MVC-API.
So — that’s basically it. Having MVC outside the Java-EE envelope does not look as bad anymore, if future versions of Wildfly, Glassfish, TomEE or Websphere decide to ship extensions like this out of the box once Ozark hits 1.0.
Disclaimer:
The subsystem is based on the latest development snapshot of Ozark, so there could still be issues and you might want wait a little longer before using this in production.
