JGF1 (322) [Avatar] Offline
P8 never write a lick (odd colloquialism)
You also never mentioned what IoC/DI brings to table. Eases testability. Reduces need for in container testing etc.
For me rules engine integration was a big plus too. But this fits under best of breed umbrella and is a more escoteric reason.
P9: re-edit?
, and the business models we build need user interfaces.
. And the business models we build, need user interfaces.
P13 Fig 1.4 title: Spring.s -> Spring
P18: Can I suggest all listing headings like 1.6 start with artifact name in them. Makes cursory scan of book as reference much easier.
More important with XML than Java, since latter class name normally makes it self evident. (Or a comment in such files).
Ditto Listing 1.8 - assume ApplicationContext.xml
P20 Parts 2 and 3 are full of real-world examples—
"canned Spring architecture" as one reviewer of this book put it—that we can use directly in
the projects we undertake. Move this to page 4 prior to section 1.1. It's why I'm such a big fan of book. Let reader hit this earlier on.
Would even go so far as to put on back cover. Great USP.

P26-27. However, if we were to simultaneously inject JdbcAccountDao into another bean with singleton scope , that bean would maintain a
reference to a separate instance.
(add such as accountService2 after comma?) Had to re-read to get gist.
P27 Fig 1.8
This diagram and associated figure heading are unclear. Have to re-read to unravel meaning. Maybe tie in to dao/service conversation above to convey point.
For me main issue is: Dependency/Dependent. Terms are too abstract to understand your meaning. Use references instead.
Eg A prototype with singleton only references will be cached
P27 safe to change and work with because -> safe to change and work with, because
P32 This isn't the only way to do it; the context namespace supplies a qualifier element we could have nested in our AccountDao declarations.
(append within the Application.context.xml or ... our 'XML' AccountDao declarations)

P33 <context:component-scan> I take it there will be multiple ones of these. But one per ApplicationContext.xml corresponding to architectural layering.
(see P16 comment)
P34 1.5.4: XML v Annotations.. I'm into Grails in a big way too. It's DSL capabilities are taking concept of annotations with metadata to next level of abstraction again. I'm all for annotation. My take. You'd only want to code an extra XML artifact if you generate it with some sort of tool or Grails plugin that configures underlying artifiacts. Otherwise complexity takes over. Can see flip side where it helps configurers. You also made no comment over whether XML would take precidence over annotations either.
willie.wheeler (110) [Avatar] Offline
Re: Review notes for Chapter 1: Second pass
Hey Jeremy. As always your feedback is really helpful. I'm adding your suggestions to our todo list. smilie Thanks!