Pretty faces shall not use http session

[GoogleCodeExporter]

PrettyContext.getInstance() line 125

PrettyConfig prettyConfig = (PrettyConfig) 
request.getSession().getServletContext().getAttribute(CONFIG_FILES_ATTR);

This leades to the creation of an http session. Outr application is stateless.

What is the expected output? What do you see instead?
request.getServletContext() also returns a servlet contest.

What version of PrettyFaces are you using? On what server and version,
version of JSF, and other relevant technologies?
pretty-faces 3.1.0

Original issue reported on code.google.com by francis....@gmail.com on 23 Sep 2010 at 3:58

[GoogleCodeExporter]

The problem is realy bodring me. Contrary to what i suggested above, i noticed 
the the request doens't return the ServletContext.

But the ServletContext is still held by the PrettyFilter and can also be 
returned from the faces context. Then the newInstance method of PrettyContext 
can be extended to look like: newInstance(final HttpServletRequest request, 
ServletContext servletContext). Avoiding to instantiate a session just to get 
to the servletContext.

Original comment by francis....@gmail.com on 23 Sep 2010 at 9:39

[GoogleCodeExporter]

This should be fixed in version 3.1.1-SNAPSHOT, can you give it a shot?

Original comment by lincolnb...@gmail.com on 30 Sep 2010 at 8:58

[GoogleCodeExporter]

@Lincoln: 
The only reference to "getSession()" currently in our code is this one:

http://code.google.com/p/prettyfaces/source/browse/prettyfaces/trunk/core/src/ma
in/java/com/ocpsoft/pretty/PrettyContext.java#168

Is there any reason why you use "request.getSession().getServletContext()" to 
obtain the ServletContext? Why not use "request.getServletContext()"? This way 
we won't need to call "getSession()".

Original comment by chkalt on 7 Oct 2010 at 7:11

[GoogleCodeExporter]

Because this is only available since Servlet 3.0. Unless we want to use a 
static variable access (which is going to break multiple simultaneous deployed 
applications using PrettyFaces,) I'm not sure I see a way around this.

Original comment by lincolnb...@gmail.com on 7 Oct 2010 at 1:48

[GoogleCodeExporter]

OK, sorry, I haven't seen that it requires Servlet 3.0!

What about a ThreadLocal? Instead of storing the PrettyContext in a request 
attribute we could bind and unbind the PrettyContext to a ThreadLocal in the 
PrettyFilter where we have a reference to the ServletContext. The same way 
FacesContext is handled.

Just a crazy idea that just came to my mind. :-)

Original comment by chkalt on 7 Oct 2010 at 3:42

[GoogleCodeExporter]

That's actually what I had originally, and I think in a flurry of attempting to 
debug the whole sporadic nullpointer/facecontext issue I went with this 
instead. We can try it again now that FacesContext is never touched in 
PrettyFilter.

Original comment by lincolnb...@gmail.com on 7 Oct 2010 at 3:59

[GoogleCodeExporter]

Yeah! I remember the problems we had with FacesContext that was not released 
properly. We _could_ try again this way. The code of PrettyFilter is much 
cleaner now. But I don't think it should be done right _now_. Especially if 
your last code changes fixed this bug. It would be good to know if the problem 
is fixed now.

@francis: Did you have any time to test if the problem still exists in the 
current snapshots? You just have to add the following maven repository and 
update the version to 3.1.1-SNAPSHOT:

    <repository>
      <id>ocpsoft</id>
      <name>OcpSoft</name>
      <url>http://ocpsoft.com/repository/</url>
      <releases>
        <enabled>true</enabled>
      </releases>
      <snapshots>
        <enabled>true</enabled>
      </snapshots>
    </repository>

Original comment by chkalt on 8 Oct 2010 at 5:53

[GoogleCodeExporter]

Resolved using the ServletRequest.get/setAttribute() map. Please verify.

Original comment by lincolnb...@gmail.com on 18 Oct 2010 at 4:57

• Changed state: Fixed