Migration Solutions for ColdFusion Applications to ASP.NET
      
New Atlanta Product Forums Profile | Search | Login | RSS
New Topic Reply   Previous Page  Page: 1   Next Page

Thread: ‘User session expired’ problem with IceFaces
Created on: 09/26/08 04:01 PM Replies: 3
pankajsingla


Joined: 09/23/08
Posts: 7
‘User session expired’ problem with IceFaces
09/26/08 4:01 PM

Hi,

We are trying to use our JSF implementation with IceFaces using ServletExec 6.0 but we are having problems with ‘User session expired’on each click of the application . We are using the same war file in Tomcat and it is working fine.

Any help in solving this problem is appreciated.


Thanks,

Pankaj
Link | Top | Bottom
mattm


Joined: 10/10/07
Posts: 266
RE: ‘User session expired’ problem with IceFaces
09/26/08 4:38 PM

Hello Pankaj,

I'm glad that you posted this question here on this forum.
Maybe someone on this forum (an SE user) has had experience getting IceFaces to run in ServletExec 6.0.

In the interest of putting all the information "out there" I will copy/paste the 3 email replies I've sent out today regarding this same issue.

Perhaps a detail or 2 there could help someone else to help you further than I can at this point.


====
email #1
====
Which version of tomcat 6?
6.what.what?

I ask because address.war won't even deploy in my Tomcat 6.0.10.
It gives me NullPointerException.


Also, have you seen ICEfacesGettingStartedGuide.pdf ?
Chapter 3 there is entitled "Running the ICEfaces Sample Applications"

There it says:

---------
... these applications are available in prebuilt
.war files suitable for deployment to Tomcat 6 ...


If you would like to deploy the sample applications to an application server other than Tomcat 6, you
will need to build the .war file appropriate for the target application server.


Individual application servers may require a different set of libraries in the
application .war file, depending on which libraries they provide themselves; thus,
it is not feasible to deploy the same .war file to all application servers.
---------


In most cases a webapp that runs fine on Tomcat will also run fine on ServletExec.
But for webapps that are very sensitive to JAR file dependencies this is not always so.

So the problem *may* be that you need to add/remove JARs from the WEB-INF\lib\ folder of the address.war file.
You can look in ServletExec's main lib folder to see which JARs ship with SE 6.
Specifically these are:

-------
activation.jar
appserv-jstl.jar
el-api.jar
jasper-el.jar
jsp-api.jar
jstl.jar
mail.jar
servlet-api.jar
ServletExec60.jar
ServletExecAdmin.jar
-------

So for example, the address.war contains jstl.jar... a version which is smaller than the one comes with SE.
So maybe remove the jstl.jar from address.war since SE already comes with it's own (newer) jstl.jar.

I am not saying that that alone will solve this problem. I'm only trying to point out what the IceFaces documentation says.



====
email #2
====
Raju,

I downloaded Tomcat 6.0.18 and found that the address.war worked fine there.
I suppose I would expect it to since the IceFaces documentation lists Tomcat as an officially supported Application Server.
I guess there is a bug in Tomcat 6.0.10 that was causing the NullPointerException I was seeing there.

I saw these IceFaces startup messages in Tomcat's (6.0.18) logging:

----
Sep 26, 2008 1:27:22 PM com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Sun's JavaServer Faces implementation (1.2_04-b10-p01) for context '/address'
Sep 26, 2008 1:27:22 PM com.icesoft.faces.application.D2DViewHandler <clinit>
INFO:
ICEsoft Technologies, Inc.
ICEfaces 1.7.1
Build number: 6
Revision: 16923
----

But with SE 6 I see this (slightly different) IceFaces startup output:

----
Sep 26, 2008 1:29:49 PM com.sun.faces.config.ConfigureListener contextInitialized
INFO: Initializing Mojarra (1.2_08-b06-FCS) for context '/address'
Sep 26, 2008 1:29:50 PM com.sun.faces.spi.InjectionProviderFactory createInstance
INFO: JSF1048: PostConstruct/PreDestroy annotations present. ManagedBeans methods marked with these annotations will have said annotations processed.
Sep 26, 2008 1:29:50 PM com.icesoft.faces.application.D2DViewHandler <clinit>
INFO:
ICEsoft Technologies, Inc.
ICEfaces 1.7.1
Build number: 6
Revision: 16923
----

So with Tomcat, Sun's JSF is used.
But with SE, something called "Mojarra" is used.

I googled and found:
https://javaserverfaces.dev.java.net/

so it seems to me that "Mojarra" may simply be the (new) name of the JSF project within Glassfish (i.e. the reference implementation of JSF).
I suspect that the mojarra classes are those found in jsf-api-1.2.jar & jsf-impl-1.2.jar which are in the WEB-INF\lib\ of address.war,
but I don't know that for certain.

It is clear to me that address.war is loading and using a different set of JSF classes depending on the Servlet/JSP Engine "brand" in which it is running.
I don't know if this is the cause of the problem but it seems to me that it very well might be.

At the very least it is something that needs to be understood.
Why would address.war choose to ignore the newer JSF classes inside it's own WEB-INF\lib folder in favor of the older
JSF classes that are bundled with Tomcat?

And how does that impact how that webapp runs?
These are questions that I can't answer.
Someone in the IceFaces community may be able to answer them.

The address.war application is behaving differently depending upon which Servlet/JSP engine brand it is running inside.
I've tried many combinations of adding/removing various JAR files from the address.war deployed on SE 6... trying to see
if some JAR file dependency/mismatch is the culprit, but I've had no success in solving the problem.

I recommend that you ask the IceFaces community (perhaps via their online forum) to see if you can get some help from an IceFaces expert.
Someone familiar with the IceFaces code and the various reasons why it would say "User Session Expired".

Please understand... it is not enough to just say "This works in Tomcat, but not in SE, therefore it is SE's fault".

Could this problem be due to a bug in ServletExec?
Maybe, but at this point I see no evidence of that... no error messages to suggest it.

What I do see is a 3rd party web application whose documentation says that its sample deployments are very specific to the Application Server brand
(i.e. not very portable sample apps).
What I do see is that the ANT build file leveraged in the address-demo folder that comes with IceFaces contains distinct targets for building
an address.war for use with distinct app server brands:

----
C:\Documents and Settings\matt\My Documents\technical\ICEfaces-1.7.1-bin\iceface
s\samples\address-demo>ant help
Buildfile: build.xml

help:
[ice-help] <<<project address has 14 available build targets, default build target tomcat6.0>>>
[ice-help] clean.........................clean the directory
[ice-help] glassfishv2...................war file for SUN Glassfish V2
[ice-help] jboss4.0......................war file for JBoss 4.0.5
[ice-help] jboss4.2......................war file for JBoss 4.2
[ice-help] jetty6.1......................war file for Jetty 6.1
[ice-help] oc4j..........................war file for OC4J
[ice-help] pe9...........................war file for SUN Application Server PE9
[ice-help] tomcat5.x.....................war file for Tomcat 5.x
[ice-help] tomcat6.0.....................war file for Tomcat 6.0
[ice-help] weblogic8.1...................war file for Weblogic 8.1
[ice-help] weblogic9.2...................war file for Weblogic 9.2
[ice-help] websphere6.0..................war file for IBM Websphere 6.0.2
[ice-help] websphere6.1..................war file for IBM Websphere 6.1
[ice-help] help..........................display this help message
----

So it is quite clear that that webapp is not too portable between app server brands (unless you build a new .war each time).
But none of the targets are meant for ServletExec.
Does IceFaces support ServletExec?

It seems to me that the IceFaces code is written with certain Servlet/JSP engine brands in mind... and not others.
In other words, I tend to think that IceFaces is doing something in it's code that perhaps it should not be doing when running on ServletExec.
Perhaps it is assuming the presence of certain classes that are not in the SE environment,
or getting tripped up on classes that *are* included with SE.
Something that's causing it to say "User Session Expired"

I really just don't know.
You need someone from the IceFaces community to help you get IceFaces working on ServletExec.

I do know that the Mojarra example named "jsf-guessNumber.war" works fine on SE 6.0 once you add jsf-api.jar & jsf-impl.jar to it.
I downloaded the latest version of Mojarra here:
https://javaserverfaces.dev.java.net/download.html

The first link is for:
https://javaserverfaces.dev.java.net/files/documents/1866/104151/mojarra-1.2_09-b02-FCS-binary.zip

which I downloaded and unzipped.
It contains a lib folder where I found jsf-api.jar & jsf-impl.jar.
It contains a samples folder where I found jsf-guessNumber.war which I unpacked so I could put jsf-api.jar & jsf-impl.jar into its
WEB-INF\lib folder (see section 7.2 of the ServletExec 6.0 User Guide).

I then deployed it on SE 6 and accessed its index.jsp and guessed the number.
So... JSF 1.2 code runs fine on SE 6.

So that sort of makes me wonder... what does the IceFaces example named "address.war" do differently as compared with the Mojarra example
named "jsf-guessNumber.war" to account for the difference in behavior?

If you can uncover some clues (perhaps by turning on debugging output within IceFaces) to help us see exactly why IceFaces thinks that the "User Session Expired"
then I might be able to offer better assistance. It would be nice if that app would output some messages like:
"I'm about to return a response to the client telling it that the User Session Expired... I'm about to do this because XYZ".

The XYZ is the clue that's need to *begin* solving this.

I also have some experience getting MyFaces to work on SE.
I know you are not using MyFaces... you are using IceFaces.
But I believe there is a point worth making here.
I will send you another email in a moment to give further details which may be useful in your efforts with IceFaces.

====
email #3
====
Raju,

Here are some details surrounding my efforts getting an older MyFaces to work with ServletExec 5.0 (a couple of years ago).
I offer these to you now simply to show that complex projects such as MyFaces (or perhaps IceFaces) are not often tested by their developers on ServletExec, and therefore sometimes issues can arise which involve changes to be made on both sides.



--------
The example that comes with MyFaces 1.0.8 (and also with 1.0.9rc3)
has bad TLD's in it.

These TLD's contain duplicated attributes for the same tag.
Tomcat 5 was not complaining about this. But SE 5.0 was.
This issue was reported to the MyFaces developers (in April 2005) who
agreed that this was a bug in the MyFaces example.

The duplicated attributes were commented out of the relevant TLDs which
resolved that problem. Details about this may be viewed here:
http://issues.apache.org/jira/browse/MYFACES-206

Once past that issue, an SE bug was discovered:
Bug #1921 entitled:
"Custom tags that use a full closing tag as in <a:b></a:b> should be treated the same as those that don't as in <a:b/>"

It was fixed in the June 2005 hotfix.

The description of that bug is:

---
This only becomes a problem if the TLD that defines the custom tag uses
<body-content>empty</body-content>, thus mandating that the tag have an empty body.
In this case, a tag that uses a full closing tag such as <a:b></a:b> was resulting
in SE incorrectly throwing an exception:

"JspServlet: action <name-of-the-action> cannot have a body."
---

its workaround is:

---
If you have custom tags that are not allowed to have a body, then use
<a:b/> instead of <a:b></a:b> in your JSPs.
---


So with SE 5.0, running the MyFaces example requires both a fix to their their example
as well as the June 2005 hotfix (or newer).

Note, to run JSF code in SE, you may also need the fix for SE bug #1833.
For more details see:
http://www.newatlanta.com/c/products/servletexec/self_help/archiveSearch/detail?page=1&messageId=88800
Like bug #1921, that bug was fixed in SE's June 2005 hotfix.



Matt
Matt McGinty, New Atlanta Technical Support
Link | Top | Bottom
mattm


Joined: 10/10/07
Posts: 266
RE: ‘User session expired’ problem with IceFaces
01/02/09 4:58 PM

I was able to get the IceFaces example named "address.war" to work inside SE 6.0.

I simply added a request filter to that webapp which just gets the session object and then calls through to the requested resource.

Here is the filter code I used:

------
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;


public class GetSessionFilter implements Filter
{   
   private FilterConfig fConfig    = null;
   
   public void init(FilterConfig fConfig)
   {
      this.fConfig = fConfig;
   }
   
   public void destroy()
   {
   }
   
   public FilterConfig getFilterConfig()
   {
      //this method is declared in the Filter Interface and so must be implemented here.
      return fConfig;
   }
   
   public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws ServletException, IOException
   {
      //The API requires that the signature of doFilter()
      //uses ServletRequest and ServletResponse.
      //But HttpServletRequest and HttpServletResponse are much
      //more useful in this method. So we cast them here
      
      HttpServletRequest req    = (HttpServletRequest) request;
      req.getSession();
      chain.doFilter(request, response); //Note: we pass them as ServletRequest and ServletResponse here.
   return; //this filter has done it's job.    
   }   
}
------

and here are the entries I added to the web.xml file:

------
<filter>
<filter-name>GetSessionFilter</filter-name>
<description>Helps IceFaces 1.7.2 to work on SE 6.0</description>
<filter-class>GetSessionFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>GetSessionFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
------

This issue was due to a bug in SE's implementation of Request.isRequestedSessionIdValid().

I've entered it into the SE bug tracking database as bug #3153 entitled:
"Must call request.getSession() before request.isRequestedSessionIdValid() will
work as expected"

I've already fixed that bug in SE 6.0 code so when the next SE update is released, one could simply use that update rather than using the above-suggested filter.

Note that the filter code suggested above could alternatively be placed into a Request Listener.

I solved this by step-debugging the IceFaces code.
I found that com.icesoft.faces.webapp.http.servlet.SessionVerifier.service() was calling request.isRequestedSessionIdValid() which was returning false when it should not have been.

I'm glad I didn't pay the $1900.00 that IceSoft wanted to look into this issue.

Please let me know how this goes for you (assuming you are still interested in running IceFaces on SE 6.0).

Matt
Matt McGinty, New Atlanta Technical Support
Link | Top | Bottom
mattm


Joined: 10/10/07
Posts: 266
RE: ‘User session expired’ problem with IceFaces
01/02/09 5:49 PM

For completeness, here are links to other forum posts regarding this issue:

http://jira.icefaces.org/browse/ICE-3777

http://www.icefaces.org/JForum/posts/list/0/10236.page#44681

Matt
Matt McGinty, New Atlanta Technical Support
Link | Top | Bottom

New Post
Please login to post a response.


company media information terms of use privacy policy contact us
This page was dynamically built on the BlueDragon CFML Engine