Public review of JSR-371, Model-View-Controller (MVC) version 1.0 specification, is now open. This is the first major release since Oracle transferred ownership to Ivar Grimstad in April 2017. Christian Kaltepoth, senior software developer at Ingenit GmbH, joined Grimstad as co-specification lead shortly after the transfer. JSR-371 was subsequently licensed under the Apache License 2.0, and in October 2017, Grimstad announced his intent to transfer MVC 1.0 to the Eclipse Foundation after its final release.
New features since the Early Draft Review 2 include:
- Internationalization - supports I18N.
- Improved data binding - enables MVC-specific rules for data binding and validation using the
@MvcBinding
annotation and theBindingResult
class.
As listed in the specification documentation, the goals of MVC 1.0 are:
- Leverage existing Java EE technologies.
- Integrate with CDI (JSR-346) and Bean Validation (JSR-349).
- Define a solid core to build MVC applications without necessarily supporting all the features in its first version.
- Explore layering on top of JAX-RS for the purpose of re-using its matching and binding layers.
- Provide built-in support for JSPs and Facelets view languages.
The Eclipse Ozark project for EE4J provides a full implementation of JSR-371 that supports RESTEasy, Jersey, and Apache CXF. It is anticipated that Ozark version 1.0 will be released in the second quarter of 2018 in conjunction with the final release of JSR-371.
Getting Started
The @Controller
annotation defines an MVC 1.0 controller as shown below with a very simple example that renders a JSP file:
@Path("hello")
@Controller
public class HelloController {
@GET
public String view() {
return "hello.jsp";
}
}
The method return types in an MVC 1.0 controller class are handled in various ways. For example:
void
- must be decorated with the@View
annotation (see example below).String
- returns a path to a view (see example above).- JAX-RS
Response
- allows full access to an HTTP response including the headers (see example below).
Shown below is a typical example of an MVC 1.0 controller (from the hello-cdi
example in Grimstad's GitHub repository):
@Path("hello")
@Controller
public class HelloController {
@Inject
private BindingResult br;
@Inject
private Messages messages;
@Inject
private HelloBean helloBean;
@GET
@View("form.jsp")
public void form() {
}
@POST
public Response formPost(@Valid @BeanParam HelloForm form) {
if (br.isFailed()) {
messages.setErrors(
br.getAllValidationErrors().stream()
.collect(toList()));
return Response.status(BAD_REQUEST).entity("form.jsp").build();
}
helloBean.setFirstName(form.getFirstName());
helloBean.setLastName(form.getLastName());
return Response.status(OK).entity("hello.jsp").build();
}
}
Autowired into the controller are instances of BindingResult
(for validation) and models, Messages
and HelloBean
, using the @Inject
annotation. The view will render form.jsp
, as specified in the form()
method, annotated by @View
. The method formPost()
returns type Response
and handles validation. The HelloForm
class defines string lengths for user input validation:
public class HelloForm {
@MvcBinding
@NotNull
@Size(min = 1, max = 16)
@FormParam("firstName")
private String firstName;
@MvcBinding
@NotNull
@Size(min = 2, max = 24)
@FormParam("lastName")
private String lastName;
public String getFirstName() {
return firstName;
}
public void setFirstName(String firstName) {
this.firstName = firstName;
}
public String getLastName() {
return lastName;
}
public void setLastName(String lastName) {
this.lastName = lastName;
}
}
The specification documentation describes the process of binding and validation:
Parameter bindings such as
@FormParam
and@QueryParam
may be annotated with@MvcBinding
to enable MVC-specific binding rules. For MVC bindings a failed validation does not result in aConstraintViolationException
being thrown. Instead, the correspondingConstraintViolation
is stored in a request-scoped instance ofBindingResult
which can be injected into the controller. This allows the controller to handle the error instead of relying on a global error handling mechanism like anExceptionMapper
.
Running the hello-cdi
example application presents the user with the following page after being rendered by form.jsp
:
User input, as shown below, satisfies the string length validation and renders hello.jsp
:
Shown below is the result of a validation error which, in this example, will clear out the input and display the error messages:
Grimstad, principal consultant for the Cybercom Group, spoke to InfoQ about this latest status of MVC 1.0.
InfoQ: Why did Oracle drop support for MVC 1.0?
Ivar Grimstad: This is actually something for Oracle to comment on. My understanding of the reasoning for Oracle's decision to drop MVC 1.0 from the scope of Java EE 8 was that they perceived MVC to be irrelevant for cloud applications since they usually ship headless.
InfoQ: When do you anticipate MVC 1.0 being integrated into EE4J? What needs to be done before that can happen?
Grimstad: We have already created a project proposal for Ozark, the reference implementation of MVC 1.0. The project proposal can be seen here: https://projects.eclipse.org/proposals/eclipse-ozark
We expect to integrate the rest of MVC 1.0 into EE4J shortly after we have released version 1.0 through the JCP. The plan is that we should be able to do that some time during Q2 this year. The reason why we have chosen to do it this way is that we want MVC to have reached the Final Release status before being transferred.
InfoQ: With APIs such as Rest Client 1.0 and JAX-RS 2.0 that are integrated into MicroProfile 1.3, would the MVC 1.0 API be a natural fit for MicroProfile?
Grimstad: Technically, you can run MVC 1.0 applications on top of MicroProfile. However, since the objective of MicroProfile is to optimize Enterprise Java for microservices, I am not sure if MVC actually fits in under the MicroProfile umbrella. It is a complementing technology and since it is running on the same stack it works very well together. A better home for MVC will be under the EE4J umbrella.
InfoQ: What's on the horizon for MVC 1.0?
Grimstad: The next thing up for MVC 1.0 is the Public Review Ballot which will take place between February 6-12. After that we will continue the work of finalizing the specification. The current plan is to have a final release in Q2 2018.
Our progress and ways to contribute can be found here:
InfoQ: What are your current responsibilities, that is, what do you do on a day-to-day basis?
Grimstad: On a day-to-day basis I work as principal consultant for Cybercom Group in Sweden. I do write code on a daily basis and stay up-to-date on current technologies by participating in open source projects and speaking at conferences. I am in the Executive Committee in the JCP as well as the PMC for EE4J.
Resources
- MVC 1.0 by Example by Ivar Grimstad (May 22, 2017)
mvc-samples
GitHub repository by Ivar Grimstad