I think that there are some important topics that are not covered by the chapter:
• The “default” section, when is it invoked by Spring and how we can take advantage of it (i.e. applying a default profile when none are set on the CLI or ENV).
• The inclusion of another section with spring.profiles.include
• What about profile-specific sections living inside a profile-specific yaml files, which file/section will be examined and in what order.
• The bootstrap.yml file, what is it used for, what configuration can/must we put in it.

What disappoint me the most is that you don’t give any advice on how to setup good configuration:
• Shall we structure our configuration by platform (application-dev, application-prod) and/or by domain (application-security, application-persistance)
• How to debug a non-functional configuration.
• How to reduce the reliance on configuration properties by developing our own auto-configuration classes.
• How to override configuration properties with configuration files external to the packaged application. Will it still work if the application id deployed in a Tomcat instance or in CloudFoundry.

With an ‘in action’ book I’m looking for advices and best practices from an experienced practitioner but as it is right now, the chapter five “working with configuration properties” doesn’t gives more information that the official documentation from Spring.

Com’on, you have been a Spring team insider and now you are at Pivotal, the worldwide Spring consulting specialists, you must know more than that.

- Do you plan to include a chapter on the subject of managing multi-datasources and achieving multi-tenancy with Spring-boot.

I think this is an important matter because:
1. new applications are often built with the requirement to address Multi-Tenancy.
2. old applications are often rebuilt with the responsibility to maintain access to legacy database in addition to their brand new databases: this implies managing two or more datasources - possibly with different database generation (SQL and NoSQL).

I own all past versions of "Spring-in-action" plus a couple of books on Spring-boot, among them "Spring-boot-in-action", but none of them talk about managing multiple datasources or multi-tenancy. This is almost like if it was not possible to achieve with spring or spring-boot. This is a great opportunity to be the first and maybe the only one book that address this problematic.


Are you going to include some paragraphs about the OAuth2 configuration ?
I think it is important to complete the chapter 4 about spring security.


When trying to build the first docker as described on chapter 1, I get a error from git:

fatal: unable to access 'https://github.com/docker-in-practice/todo.git/': Could not resolve host: github.com

As a complete noob on Docker I was shocked and completely discouraged right from the beginning.

I had to go on google to try to understand the problem (corporate firewall and so on) and maybe find a solution.
I found many resources, none of them understandable for a complete noob!


I would have liked the book to talk about the possibility of this problem occurrence and the corresponding solution.

Closed the book, and pass my way.

In section 2.1.1 Layered Architecture", you end up the discussion about the Business Layer in saying:
<<In some systems, this layer has its own internal representation of the business domain entities. Alternatively, it relies on a Domain Model implementation, shared with the other layers of the application. We'll have much more to say about this aspect later in this chapter. >>

I have read the whole chapter but couldn't find the promised dissertation about sharing Domain Model Object across application layer.

I am inclined to let the Entities objects bubble up the layers up to the Presentation layer. But I have seen many projects where Entities get replicated from layer to layer either by hand or by using Dozer, pretending that it shield the copy in the current layer from implementation changes in the source object pertaining to the below layer.

Entity Replication vs. Bubble-up is a topic that I would very much like see analyzed by you as specialists. Could you include a few sections on this topic, which state precisely what we can do with Entity objects?

Thanks in advance.

This is not really an error, but don't you think that the illustrations are a bit gigantic. We would certainly suffer no loss in comprehension if the illustrations were more modest in size. On the contrary, having more illustrations on the same page would reduce the dispersion and would help comparing them together.
Thank you for pointing that out.
So, only the property: function() {...} form is valid in both situations. Maybe that explain why the book is using that form so much.
That call for an explanation anyway, because the other form is more natural (for people coming from java)

whoa, apparently there is much to discover about javascript function (declaration forms, usage patterns, etc).

I duno if what JohnMick wrote in its previous post is in the book (I've only read 1/4 of the book so far) but sure it could find its place there.

I can't wait for the next MEAP...

Thank you all for sharing your knowledge.

could you add a few sentences clarifying the differences or similarities of defining methods as a) named functions or b) anonymous functions affected to properties.

var myObject = {
function method1() { ... };
method2: function() { ... };

Does it make any differences? What is the arguments for and against each form of method definition?

Same questions when defining inner functions:

function outer() {
function method1() { ... };
method2: function() { ... };

I have noticed that the polices used in the last MEAP have changed to a Sans-Serif police (I think it is Arial). This is realy unfortunate because it render the book really difficult to read.
Please could you switch back to a Serif font, like TimesNewRoman or Garamond ?
I have sent an email to Manning to express my concern about that new font used in the book.

In the meanwhile, can everybody who is unsatisfied with the new font, send a email to maba@manning.com to let them know.

IMHO, by the time your code reach the controller, the persistance session will be closed and it will be too late to load lazy objects in the returned object.