Прочитать книгу Spring in Action

The chapter covered:

• Adding project dependencies with Spring Boot
• starters
• Automatic bean configuration
• Groovy and the Spring Boot CLI
• The Spring Boot Actuator

Spring Boot is an exciting new addition to the Spring family of projects. Where Spring aims to make Java development simpler, Spring Boot aims to make Spring itself simpler.

Spring Boot employs two main tricks to eliminate boilerplate configuration in a Spring project: Spring Boot starters and automatic configuration.

A single Spring Boot starter dependency can replace several common dependencies in a Maven or Gradle build. For example, adding only Spring Boot’s web starter as a dependency in a project pulls in Spring’s web and Spring MVC modules as well as

the Jackson 2 databind module.

Automatic configuration takes full advantage of Spring 4.0’s conditional configuration feature to automatically configure certain Spring beans to enable a certain feature. For example, Spring Boot can detect that Thymeleaf is in the application classpath and automatically configure the beans required to enable Thymeleaf templates as Spring MVC views.

Spring Boot’s command-line interface (CLI) further simplifies Spring projects with Groovy. By simply referencing a Spring component in Groovy code, we can trigger the CLI to automatically add the necessary starter dependency (which may, in turn,

trigger automatic configuration). Moreover, many Spring types don’t require explicit import statements in Groovy code run via the Spring Boot CLI.

Finally, the Spring Boot Actuator adds some common management features to a Spring Boot–developed web application, including insight into thread dumps, web request history, and the beans in the Spring application context.

That was a cool chapter about:

• Exposing Spring beans as managed beans
• Remotely managing Spring beans
• Handling JMX notifications

With JMX, you can open a window into the inner workings of your application. In this chapter, we saw how to configure Spring to automatically export Spring beans as JMX MBeans so that their details can be viewed and manipulated through JMX-ready management tools. We also learned how to create and use remote MBeans for times when those MBeans and tools are distant from each other. Finally, we saw how to use Spring to publish and listen for JMX notifications.

Email is an important form of human-to-human communication and frequently a crucial form of application-to-human communication as well. Spring builds on the email capabilities provided in Java, abstracting JavaMail for simpler use and configuration in a Spring application.

In this chapter, we’ve seen how to use Spring’s email abstraction to send simple email messages, and you’ve taken it further by sending rich messages that contain attachments and that are formatted with HTML. We also looked at using templating

engines like Velocity and Thymeleaf to generate rich email text without resorting to creating HTML via string concatenation.

Messaging with WebSocket and STOMP

This chapter covered

• Sending messages between the browser and the server
• Handling messages in Spring MVC controllers
• Sending user-targeted messages

I've learned WebSocket from this chapter and how it works with bare JS, and a cool SockJS wrapper for those browsers that don't support WebSockets.

And even more, there is a STOMP protocol that brings another abstact layor over Websockets.

WebSocket is an exciting way to send messages between applications, especially when one of those applications is running within a web browser. It’s critical for writing highly interactive web applications that seamlessly transfer data to and from the server.

Spring’s WebSocket support includes a low-level API that lets you work with raw WebSocket connections. Unfortunately, WebSocket support is not ubiquitous among web browsers, servers, and proxies. Therefore, Spring also supports SockJS, a protocol that falls back to alternative communication schemes when WebSocket doesn’t work.

Spring also offers a higher-level programming model for handling WebSocket messages using the STOMP wire-level protocol. In this higher-level model, STOMP messages are handled in Spring MVC controllers, similarly to how HTTP messages are handled.

The chapter was about messaging - async way of communication between applications. It covered:

• Messaging with JMS
• Sending messages with Spring and AMQP
• And async message-driven POJO

Asynchronous messaging presents several advantages over synchronous RPC. Indirect communication results in applications that are loosely coupled with respect to one another and thus reduces the impact of any one system going down. Additionally,

because messages are forwarded to their recipients, there’s no need for a sender to wait for a response. In many circumstances, this can be a boost to application performance and scalability.

Although JMS provides a standard API for all Java applications wishing to participate in asynchronous communication, it can be cumbersome to use. Spring eliminates the need for JMS boilerplate code and exception-handling code and makes

asynchronous messaging easier to use.

In this chapter, we’ve seen several ways that Spring can help establish asynchronous communication between two applications by way of message brokers and JMS.

Spring’s JMS template eliminates the boilerplate that’s commonly required by the traditional JMS programming model. And Spring-enabled message-driven beans make it possible to declare bean methods that react to messages that arrive in a queue or

topic. We also looked at using Spring’s JMS invoker to provide message-based RPC with Spring beans.

Alsow there was extension of JMS messaging standard - AMQP, that brings new several type of messaging queues.

BTW, for now I finished the book! :) will describe all the chapters a bit later.

meanwhile, chapters 17 and 18 are finished. Will be summarized later.

The chaper covered such things like:

• Writing controllers that serve REST resources
• Representing resources in XML, JSON and other formats
• How to consume REST resources

So, you just write your regular controllers. And then you have to transform the output to the apropriate format by REST, by two options:

• Content negotiation—A view is selected that can render the model into a representation to be served to the client.
• Message conversion—A message converter transforms an object returned from the controller into a representation to be served to the client

For the first option there is ContentNegotiatingViewResolver. It checks requested media type(s) and finds the best suitable view for it. The key benefit of using ContentNegotiatingViewResolver is that it layers REST resource representation on top of the Spring MVC with no change in controller code. The same controller method that serves human-facing HTML content can also serve JSON or XML to a non-human client.

Message conversion is a more direct way to transform data produced by a controller into a representation that’s served to a client. When using message conversion, DispatcherServlet doesn’t bother with ferrying model data to a view. In fact, there is no model, and there is no view.

Message conversion based on client's Accept header.

@RequestMapping(method=RequestMethod.GET, produces="application/json")

public @ResponseBody List<Spittle> spittles(

@RequestParam(value="max", defaultValue=MAX_LONG_AS_STRING) long max,

@RequestParam(value="count", defaultValue="20") int count) {

return spittleRepository.findSpittles(max, count);

}

@ResponseBody rules!

There's also @RequestBody annotation to help transforming data to entity:

@RequestMapping( method=RequestMethod.POST consumes="application/json")

public @ResponseBody Spittle saveSpittle(@RequestBody Spittle spittle) {

return spittleRepository.save(spittle);

}

Spring 4 brings @RestController annotation, that automatically treats all methods as @ResponceBody.

Also methods can return ResponceEntity<> to have ability to pass Http error codes.

@RequestMapping(value="/{id}", method=RequestMethod.GET)

public ResponseEntity<Spittle> spittleById(@PathVariable long id) {

Spittle spittle = spittleRepository.findOne(id);

HttpStatus status = spittle != null ? HttpStatus.OK : HttpStatus.NOT_FOUND;

return new ResponseEntity<Spittle>(spittle, status);

}

And there also nice @ExceptionHandler to handle errors:

@ExceptionHandler(SpittleNotFoundException.class)

public ResponseEntity<Error> spittleNotFound( SpittleNotFoundException e) {

long spittleId = e.getSpittleId();

Error error = new Error(4, "Spittle [" + spittleId + "] not found");

return new ResponseEntity<Error>(error, HttpStatus.NOT_FOUND);

}

or even:

@ExceptionHandler(SpittleNotFoundException.class)

@ResponseStatus(HttpStatus.NOT_FOUND)

public Error spittleNotFound(SpittleNotFoundException e) {

long spittleId = e.getSpittleId();

return new Error(4, "Spittle [" + spittleId + "] not found");

}

Also there was a way to set headers through ResponceEntity and HttpHeaders classes.

About consuming REST services, there's a RestTemplate with a dozen of methods.