1) Is there a DTD or some detailed documentation that is available for exceptions.xml? I did a web search on this file and noticed a link (http://jira.jboss.com/jira/browse/JBSEAM-186?page=comments) that showed a lot of proposed activity, and I'm just wondering what the final set of functionality offered by this file is. That link talks about a lot of things like ExceptionFilter, a request-scoped variable named "exception", and some different possible tags (many of which are also provided in the link in your previous post). It'd be nice to have take a look at DTD or documentation that describes all the current possibilities with the exceptions.xml file. 2) anonymous wrote : A Seam persistence context is most like a container-managed extended persistence context. But whereas the container-managed context is tied to an SFSB instance, and hence there can be multiple contexts per conversation, the Seam persistence context has exactly one per conversation. What implications does the existence of multiple persistence contexts per conversation have? (i.e. What negative consequence of this was being solved by the introduction of the Seam-Managed Persistance Context?) Is it necessary (or recommended?) to use the SMPC in all cases where there exists a conversation? - I'm not sure about the decision process for which of the two to choose, and the rationale behind it. 3) anonymous wrote : There is nothing wrong with having a bunch of stateless actions all using the same conversation-scope persistence context. This is part of the magic of Seam - components with different scopes can all work smoothly together in a loosley coupled way, with no need for orchestration by the Java code. In that case, is it correct to say that everything in Seam is stateful regardless of whether you use stateless or stateful session beans - because the component tree and state holds the information which is injected into fields of the session beans? If everything can be conveniently done with a stateless session bean because of the beauty of bijection, then when (this'll sound like a really dumb question) would you use stateful session beans at all? I imagine it'd be more than just a matter of convenience coding (e.g. saving a few merge() calls or something like that)? 4) I need some guidance here: What are best practices or suggestions regarding what to bind fields in the webpage to - session beans or entities? If you have a Registration session bean and a Person entity, would you bind fields such as "name" to the entity directly and other things like "password1" and "password2" to the session bean (because, for example, you need to make sure both passwords are the same)? Or is such a direct access to the entity not considered good (because that's what the session facade is meant for?), and even "name" should be bound to the session bean then passed through to the entity? Is it not good practice to, in a form with multiple fields, have some forms bound to #{register. } and others bound to #{person. }...should you remain consistent instead? What would you do? Thanks. Whew! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3994131#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...