Hi guys... Thank you for replying my question.
My EJB is connected to a server which running on difference machine. I do have a listener in my EJB. If something changes in the server that I connected to, it will inform my EJB straight away. The reason I ask that question is, I need to update my page for displaying the latest data that just informed by the server. My EJB have a data and EJB is the trigger point when I should update my page. Normally, the pages will requests the data from EJB. But in my case now, is the opposite way, the EJB request the page to updating the data. The reason why i need the facesContext, I need to access my manage bean and update some data in there. In my page, i do have a poll which will run and refresh the page in every few seconds. Basically, the new data will be display when pollevent is triggered. any idea? Regards, pdt NABA wrote: > > Hi Neil.. > You wrote: > > The question is whether every class should know exactly how they are > stored. And have to fetch them itself. > > > How can a class fetch them istself to the other classes! > Or is there an other method to get the objects. > I m using now: > > session.getAttribute("isBlueMonday"); > > However, this is a very good idea/approach to centrelize the access to > the session to get objects! > naba > > Neil Pitman schrieb: >> Hi Naba, >> >> The Session object and JSF are both part of the web layer. For all >> intents and purposes they are tightly bound together in webapps. I >> think that both should be unknown to EJBs or other model/data layers. >> The boundary between webapps and appservers should allow simple domain >> objects, but no technology decisions on either side; it becomes a real >> pain when you want to change a web technology, but the server has become >> dependent on it. >> >> My comment regarding HTTPSessions was more a question of clutter. >> Obviously you need essential objects, like user key, and objects related >> to the interaction or user preferences, since they are costly to obtain, >> and should be near at hand for every subsequent request. >> >> The question is whether every class should know exactly how they are >> stored. And have to fetch them itself. >> >> I would prefer a SessionWrapper class that has specific get/set methods >> with strong typing rather than a free-for-all of hardcoded session >> queries like: session.getAttribute("isBlueMonday"); >> >> The session object tends to get bloated, because everyone puts in, but >> no one dares clean it. You need to pass the session around in every >> call; it would be better to use a managed bean or a spring bean. This >> bean can certainly use the session for holding data. But, it is the >> only one holding the keys, literally. Other classes do not need to find >> the key or make sure that it's correctly initialized, or decide whether >> the whole object is stored or just the keys. And best of all, if some >> session attribute is getting corrupted, you can breakpoint the >> SessionWrapper access to it. >> >> Right now, I have a reasonably complex JSF system. I only keep the some >> keys related to the principle there. Again, for performance and >> clustering reasons, an essential (only the essential) session object is >> much better. (let's not even talk about programmer sanity!) >> >> Neil >> >> -----Original Message----- >> From: NABA [mailto:[EMAIL PROTECTED] >> Sent: November 21, 2007 3:18 AM >> To: MyFaces Discussion >> Subject: Re: Question about FacesContext >> >> Hi Neil!! >> Is it a bad thing too, to access the session in JSF?? >> I do it all the time to get some beans from the session!! >> Or do you answerd only the question from pdt! the access to a session >> >from the ejb? >> >> naba >> >> >> >> >> Neil Pitman schrieb: >> >>> Hi Pdt, >>> >>> Whoa! That does not sound like a very good thing. JSF is definitely a >>> web-layer/presentation thing. While it might work in JBoss, accessing >>> the HTTP Sessions or HTTP Requests or JSF objects are a really bad >>> >> idea. >> >>> Here is a short and incomplete list of bad things that could happen: >>> >>> 1) Web objects are not necessarily serializable, and if they are, then >>> modifications made in an EJB may be lost if the serialization is one >>> >> way >> >>> 2) Even if it works, these are big objects with complex graphs of >>> subobjects or sister objects, the performance hit could be large >>> >>> 3) JBoss is outside the EJB spec when it allows collocated web apps >>> >> and >> >>> enterprise apps to see each others' class loader. Migration to other >>> app servers will be problematic >>> >>> 4) The dependencies become nightmarish >>> >>> 5) The appserver now depends on the JSF (again, an inversion of >>> dependencies) so that a webservice might need to simulate JSF >>> >>> 6) kiss goodbye to any hope of decoupling the webserver from the >>> appserver for performance reasons. >>> >>> If there is data that you need from the context, like domain keys, >>> >> then >> >>> these should be passed in explicitly as parameters to the session >>> >> beans. >> >>> These can be fundamental types like Strings, or your own value >>> >> objects. >> >>> I have spent the last 2 months trying to understand a webapp with >>> >> every >> >>> kind of data item, control flag and return code in their HTTPSession >>> object keyed with hardcoded strings. Use simple serializable value >>> objects; life is easier that way. >>> >>> Neil >>> >>> >>> -----Original Message----- >>> From: pdt_p [mailto:[EMAIL PROTECTED] >>> Sent: November 21, 2007 12:33 AM >>> To: users@myfaces.apache.org >>> Subject: Question about FacesContext >>> >>> >>> Hi... >>> >>> I have 1 JSF ear, and 1 ejb ear deployed in a Jboss. >>> >>> normally, we execute FacesContext.getCurrentInstance() in order to get >>> current facescontext. But this method will return null when you >>> >> execute >> >>> it >>> in one of the ejb class. >>> >>> is that possible to get JSF faces context from one of ejb class? >>> if it's possible, how to do it? >>> >>> any idea >>> >>> thanks >>> >>> >>> Pdt >>> >>> >> >> > > > -- View this message in context: http://www.nabble.com/Question-about-FacesContext-tf4848184.html#a13904670 Sent from the MyFaces - Users mailing list archive at Nabble.com.