Hi Naba, I wrote that but it's not the clearest English in the world. Permit me to try again.
The question is whether every class (and especially every servlet or JSP) should know the exact business rules for the construction of session attributes, and the mechanics of their storage / retrieval. Moreover, unless one avoids creating, storing and retrieving the attributes, the same code will be repeated many times throughout the code making it virtually impossible to change the business rules or implementation. And one tends to use an unsophisticated approach, since it will be repeated many times. Neil -----Original Message----- From: NABA [mailto:[EMAIL PROTECTED] Sent: November 21, 2007 8:07 AM To: MyFaces Discussion Subject: Re: Session context was RE: Question about FacesContext 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: [email protected] >> 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 >> >> > >
