The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

RobertGloverJr (30) [Avatar] Offline
I want to make some comments on chapter 3 (Minimizing XML Configuration and Spring) while this chapter is still fresh in my mind.

The first paragraph states, ""But as your application grows, so will the amount of XML configuration you'll write. Fortunately, Spring offers a few tricks to help you cut down the amount of XML configuration required...."

I have two comments on the above. First, I believe it would be very helpful to provide some heuristics (i.e., rules of thumb) as to how much XML there has to be in order for it to be a problem of such magnitude as to require the techniques explored in this chapter for reducing the amount of XML.

The problem I see happening is that developers who have small applications are being "bum rushed" into reducing the amount of XML they use, resulting in applications that are harder for other developers to take over and maintain/enhance.

Apparently there is a certain size of the XML at which point its size becomes a problem. It would really help a lot if Craig could use his connections in the industry to find some real world examples of applications that truly are so large that the XML can be profitably reduced in such fashion that the increased difficulty of maintaining the system is a worthwhile price to pay as a trade off.

My second comment is that prior to the new Spring namespaces, it was generally accepted that Spring XML in many situations required too many overly verbose XML "incantations". That term was often used, for example, when referring to the verbose XML required for the old Acegi Security. Now however, the new name spaces in Spring have dramatically reduced the size and number of XML "incantations".

When Craig writes on page 2 of chapter 3 that "Fortunately, Spring offers a few tricks to help cut down the amount of XML....." and then lists only "auto wiring" and "auto discovery", he is (conspicuously by its absense) omitting the truly important XML reduction that resulted when Spring added the namespace support enhancements such as "util" etc etc.

It seems to me that Craig might consider commenting on the ridiculous situation whereby JSR-330 and @Inject, compete with Spring @Autowired. What politics caused this? It would be interesting for the book to give some background to this mini "Tower of Babel".

I would also like Craig to go to his industry contacts and find out what proportion of the developer community is using @Autowired, @Inject, etc., and report on what kinds of applications in the real world are using these techniques instead of the improved XML that Spring provided with the new namespaces. My guess is that maybe at most 3 percent of Spring applications written by real professional developers in corporations are using @Inject, @Autowired, etc. It seems to me Craig should explain when it is appropriate and when it is not.

Craig writes on page 23 (section 3.4), "If you're one who abhors XML then Spring 3 has something special for you."

Of course this is humorous, as is almost anything Craig writes, which is a blessing. Craig makes even the driest material seem interesting and fun.

But even so, what kind of a professional developer abhors XML? All major relational databases support the XML column type and support XQUERY to interrogate XML within the database. XPATH 2.0, XQuery 1.0, XSLT 2.0, and XMLSCHEMA second edition, are indicative of the maturation of XML. XML is going to be increasingly important and its use is going to increase, not decrease.

Using the techniques in chapter 3 to drastically reduce the amount of XML by placing metadata into the source code of java, it could be argued, is irresponsible because it will cause future maintenance programmers to require more time to do their work and increase the likelihood of unintended consequences.

Even Rod Johnson himself has written there are are situations where XML is still necessary.

I think it would be great for Craig to explore this issue in his book.