Seam and Acegi are not a good combination, because Seam pretty much implies using JSF (right now, at least) - and Acegi and JSF don't play well. Acegi is geared towards request-type view frameworks, that can be secured using URL-based rules. JSF is a component-type framework, and as such doesn't play well with URL-based security - rules tend to fire for a previously-accessed URL, instead of the currently requested one, unless one is using redirects everywhere. It's possible to integrate them on the lower (DAO/service) level, not using Acegi's security filters, but, quite frankly, I have no clue what would this give me on top on what Seam Security already provides.
Exactly the point I make in the book (chapter 11). Very well said.
In terms of integration, I was looking more at the authentication part of a Acegi and saying that it wouldn't be too hard to integrate that. Once the user is authenticated (logged in and granted roles), even with Acegi, you would definitely want to use Seam's authorization (enforcement of security).
Seam has always supported rule-based authorization based on Drools. What this let's you do is consult objects in any scope, and their properties, to determine if the user should be allowed to do something. Very powerful. In Seam 2.1, there is another layer of security in the form of persistent (database) ACLs. The latter is ideal for managing permissions through a user interface. By the way, none of Seam security requires you to use XML.