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#3994131

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3994131
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to