-
15. Re: Basic Seam questions
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)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)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! -
16. Re: Basic Seam questions
What are best practices or suggestions regarding what to bind fields in the webpage to - session beans or entities?
Bind them to what they should be bound to! If you're manipulating an object like a "Car", that has color, price, model name, etc, those should be bound directly to the car. The cool thing about Seam is that it gets rid of the whole "data transfer objects" (DTOs) thing. You certainly can use session beans as DTOs in cases where you really need to, but if you don't need to, don't! I started using Seam because I don't want to use any more DTOs. JSF backing beans are DTOs.
Why are DTOs so bad? Because they don't correspond to any part of your business. Working on stuff that's not part of your business means wasting time, effectively.
I'm a Seam newbie so I hope someone will correct me if I'm wrong on this. -
17. Re: Basic Seam questions
1)
http://www.jboss.com/products/seam/exceptions-1.1.dtd
Its also in the Seam jar.
2)
The negative consequence is that you can have multiple objects from the same persistent identity, for the same conversation.
In Seam 1.1, Seam-managed persistence contexts are very efficient in a clustered environment, and I strongly recommend them.
3)
Of course there is always per-request state. The diff b/w a SFSB and an SLSB is that an SLSB does not hold state between *method calls*. Which means that they can never be used as a backing bean for a JSF form, among other things.
4)What are best practices or suggestions regarding what to bind fields in the webpage to - session beans or entities?
The best practice is to use a stateful session bean or an entity bean. Depends upon whether the form data is to be persistent or not.
The Seam registration example does it exactly right. -
18. Re: Basic Seam questions
In Seam 1.1, Seam-managed persistence contexts are very efficient in a clustered environment, and I strongly recommend them.
SMPC is one of the pillars of Seam. Without SMPC it's pretty frustrating. I was floundering until I figured out that I needed to use SMPC. I wish that Chap. 1 of the Seam Tutorial would put more emphasis on using SMPC and explaining what it is. -
19. Re: Basic Seam questions
I have some questions about the responses above, but to have a better understanding leading up to it, I need to figure some things out about conversations.
From the Seam FAQ:Most other web frameworks store all application state in the HTTP session, which is inflexible, difficult to manage and a major source of memory leak. Seam can manage business and persistence components in several stateful scopes: components that only need to live across several pages are placed in the conversation scope; components that need to live with the current user session are placed in the session scope
Seam supports fine-grained user state management beyond the simple HTTP session. It isolates and manages user state associated with individual browser window or tab (in contrast, HTTP session is shared across all windows of the same browser).
What is the conversation equivalent of an HTTP session? Where and how is this conversation information actually stored?
How does Seam know that a new tab or window has been opened...I haven't been able to figure it out at all, but it almost seems like magic. I believe it happens with both client- and server-side state-saving. In both cases, how does it actually know of and keep track of all different conversations? -
20. Re: Basic Seam questions
Where and how is this conversation information actually stored?
By default it is actually stored in the session, but in an isolated way - a kind of "mini session" scoped just to the conversation. And then we have a timeout operating upon this.How does Seam know that a new tab or window has been opened...I haven't been able to figure it out at all, but it almost seems like magic.
Seam keeps the conversation id in the JSF component tree (and in the URL, for bookmarkable pages) and passes it as a request parameter. -
21. Re: Basic Seam questions
I believe it happens with both client- and server-side state-saving.
Right, both work. -
22. Re: Basic Seam questions
That's right, I did notice a "cid" request parameter in the address bar. However, what confuses me is if I hit CONTROL+N (for a new window) or open a new tab, how does Seam know that you are now in a new conversation and not the same one? After all, isn't it the same "cid" in the request parameter?
Similarly, with the back button, how does Seam know when it builds the component tree that these components belong to a NEW conversation and not an existing one? After all, if you click back and resubmit (with the same cid in the browser bar), wouldn't it "overwrite" the current conversation?
So if I were to look at what's within the HTTP Session, would I see multiple "cid" parameters? (By the way, if not using JSP how can you manipulate and view the HTTPSession? I'm guessing that the seam Session context isn't the same object as JSP's HTTPSession?) -
23. Re: Basic Seam questions
@Destroy - Designates a destroy method that is called when a context ends and the component is being disposed. (Seam annotation)
@Remove - Applied to a business method of a stateful session bean class. Indicates that the stateful session bean is to be removed by the container after completion of the method. (EJB annotation)
If your SFSB lives beyond the seam context and you require cleanup, then this may be different from the EJB remove method which after a successful call indicates to the container that the bean can effectively be removed from the system. It is also recommended that resource cleanup, be done in the @PreDestroy method which is called before the @Remove method is called.
Hope this provides a little more clarity. -
24. Re: Basic Seam questions
Thanks for the clarification. Here are a couple more questions I have in addition to my previous posting:
1)
Let me clarify if I have a correct understanding of annotations and lifecycle based on the past several posts. Perhaps somebody could clarify, correct or add additional info to what I describe below:
Stateful Session Bean:
A conversation begins when an action is called by a JSF view on a method marked @Begin. The conversation ends upon timeout or when a method marked @End is called.
In either case of an ended conversation, Seam calls the @Destroy method, in which the developer puts ????? code. Because that same method is required to be marked @Remove by Seam, the bean is to be discarded. Before the bean is actually discarded, though, the @PreDestroy method is called.
Stateless Session Bean:
A conversation begins when an action is called by a JSF view on a method marked @Begin. The conversation ends upon timeout or when a method marked @End is called.
In either case of an ended conversation, Seam calls the @Destroy method, in which the developer puts ????? code. Because SLSBs can't have @Remove methods, this is where I get confused for SLSBs.
2)
When we say "Seam calls the @Destroy method", what exactly is "Seam" in that context? Is it through that SeamInterceptor or some kind of SeamPhaseListener thing that we put into the Seam configuration files? How does Seam actually sit on top of JSF to do what it does? (I tried to do the debug from FacesServlet onwards, but seam-gen didn't bring include any source code in the final build so I'm tracking them down for all the JARs one-by-one. Is including the source code a worthwhile suggestion for seam-gen?)
3)
Must @Begin and @End methods be defined on the same bean class (e.g. RegisterBean), or can a @Begin method in one bean start a conversation that is ended by an @End method in another bean (e.g. MaintainRegistrationBean)? I tried it out but can't tell for sure if it's supposed to work that way or not... -
25. Re: Basic Seam questions
1) SLSBs do not need to be removed, because they are, well, stateless - they have no lifecycle (@Destroy makes no real sense either)
2)Depends. It might be coming from the phase listener, a servlet context listener, or a servlet session listener - you don't need to think about that stuff, I'm the one who worries that shit
3) They can be on different beans -
26. Re: Basic Seam questions
A conversation begins when an action is called by a JSF view on a method marked @Begin. The conversation ends upon timeout or when a method marked @End is called.
Hi Gavin,
Is there other automatic conversation end method? For instance, when user click other action/link in a process of a conversation, how to let system to end the conversation? Since I always get an exception when I click unrelative action, then come back to try to start a new same conversation. Thanks. -
27. Re: Basic Seam questions
Is there other automatic conversation end method? For instance, when user click other action/link in a process of a conversation, how to let system to end the conversation? Since I always get an exception when I click unrelative action, then come back to try to start a new same conversation.
There are various ways to disable propagation of the conversation context, described here:
http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html#d0e3794
Though I notice that this section does not talk about the use of s:link and s:button, when it certainly should do. -
28. Re: Basic Seam questions
In what case would you use a TRANSACTION-scoped persistence context on a SFSB as opposed to an EXTENDED-scope persistence context?
Ever? If so, in which cases? -
29. Re: Basic Seam questions
Whenever you did not want to hang on to the objects in memory over multiple requests.