In the beginning authors explain what is Seam, and it is understood,
as Seam is much different than any other framework with similar
functionality. Seam is not meant for using it as “white box”. It is
rather “black box”, designed for just using it, without knowing inside
details. Because of this debugging Seam code is tedious task, and in
fact unnecessary. There is chapter in the book explaining how to use
debugging mechanism built in Seam, so called “debug pages”. One can
check session state, stacktrace or JSF components tree. Very helpful
for anyone writing web applications in this framework.

There is also chapter about business processes and business rules.
Yes, this is also built in Seam. As an example in the book is ticket
system. User logs in, lists tasks and assigns them to herself.
Developer does not need to care about storing users tasks in database,
it is enough to set component scope to BUSINESS_PROCESS. This is very
interesting functionality, and although it is explained quite well in
the book, I would like it to be explained even better.

There is good testing support in Seam and this is also well described
in the book. Seam provides tools to do in tests what is normally done
by container, like dependency injection, database and transactions
mocking etc.

Another chapter is about running Seam applications on non-ejb3
containers (like Tomcat).

The book covers many topics, not only about Seam itself, but also
about how to use Seam, test, how to deploy applications on non-seam
container, how to connect to another than default database etc. The
book is targeted for real users, for people working with the
framework.

What I miss is more insight into how Seam internally works. Such
knowledge is not necessary to write working apps, but I just like to
know such things.

Some knowledge about JSF and EJB3 is also very useful when reading
this book. I would like some of this stuff explained, but on the other
hand it is book about Seam not about EJB3/JSF.

I think reading this book is very good for someone who wants to write
applications in Seam, even advanced ones. Seam is interesting
technology, much different than pure JSF+EJB3, and it’s worth
learning, even for someone not using it at work, just to see new
possibilities.
Rating: 4 / 5

Where this book lacks most is as a reference book. The reason for this is that many concepts are introduced well before the chapters that talk about them. When looking back at these concepts, I find myself having to find the first place the concept is introduced because the chapter about that assumes that you have read the earlier introduction.

Overall this is a good book for learning the basics of SEAM. However, it is not a good in-depth reference. Nevertheless, SEAM is an excellent technology and there are not yet many good books on it. This book will bring you up to speed on SEAM pretty quickly so I still recommend it.
Rating: 3 / 5

Seam(and specifically seam-gen) still has some significant bugs/issues
to iron out(but workaround exists).
Rating: 5 / 5

The book’s alternative is Seam, which is meant to be a filler between EJBs and JSF. One nice aspect is that Seam is inherently stateful. For a Web user session, this is vital, and it’s nice from the text to see state built into Seam, without you having to shoehorn it in.

Perhaps the most persuasive parts of the book are the code examples. Granted, the authors wrote these to be as concise and elegant as possible. But if you accept that most authors of computer books do this, then you can quickly appreciate the contrast between the code here and comparable code in texts on EJBs and JSF. The latter code examples are much longer and more intricate. The brevity of code writing that Seam affords you can greatly help in two ways. Quicker to write. And quicker to debug.

Having said this, I am undecided about one aspect of the text. Involving what is called “dependency bijection”. It is meant as a lightweight way for POJOs to interact with each other. As opposed to using framework interfaces or abstract classes. But the extensive use of interfaces (and abstract classes) has led to the successful development of extensible packages like Eclipse. (And I’m sure readers can cite other examples. ) Is it the case that interface implementations do have limitations, perhaps in the context of Web servers and business logic?
Rating: 5 / 5