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