This content has been marked as final. Show 6 replies
CardM wrote:And why do you think that is the case? I think you're confusing them with servlets.
because i should not inject my SFSB to any managed bean, or message driven bean (because if i do, the SFSB will be shared to all clients)
I am trying to do this way, but i got null pointer exception.You don't. The EJB layer is completely detached from any kind of web environment, and as such you don't have (reliable) access to the faces context in there. When you're using JSF you should be working with the session in a managed bean.
So, how can i do this in EJB module?
HttpSession session = (HttpSession) facesContext.getExternalContext().getSession(true);
CardM wrote:I really don't get your question. It sounds like you simply have no clue how stateful beans really work (not really strange, its far from easy) and you want someone to explain to you in a forum post what is explained in whole chapters of books. It ain't gonna happen.
ah right, it is shared with the case of servlet. Then have you got any ideas to use SFSB in EJB module? Keep it in a singleton bean and store client session in a table to access appropriate SFSB instance ?
Let me pose a counter question: why do you think you need a stateful bean? Why do you think you need to keep state in memory?
Well me: hardly. Generally there is a web layer involved with a perfectly fine session (or conversation) in which state can be maintained.
Alas you don't want to seem to really say what's on your mind with or without my prying so I'll just offer a hunch I have. A stateless bean only remains "active" as long as you keep an active connection to it; IE. the reference you lookup or inject in your client code. The "storing the bean in the session" you refer to in your first post is the act of keeping the bean alive; as long as the reference is stored in the session you can keep using it for the same client without it being cleaned up by the container. However: when working from a web layer there isn't much use for a stateful bean as you can simply use the session itself directly to hold onto stuff. Its personal preference if you use them or not really.
Where you were going wrong in your initial post is that you don't fetch the object from the HTTP session in your EJB code. But you probably already figured that out for yourself.