[ICE-3784] ICEfaces does not support sub context redirect - ICEsoft JIRA Issue Tracker

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Fixed
Affects Version/s: 1.8
Fix Version/s: 1.8
Component/s: Framework
Labels:
None
Environment:
All

Workaround Exists:

Yes
Workaround Description:

Hide
The workaround is to reduce 3 apps into two: merge the first two, like below:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd" version="1.4">
  <description>BNNP ear</description>
  <display-name>bnnp-ear</display-name>

  <!?Move the filter into the second app, I guess ICEFaces does not support sub context redirect
  <module>
    <web>
      <web-uri>url-filter-1.0-SNAPSHOT.war</web-uri>
      <context-root>/BNNP-QA</context-root>
    </web>
  </module>
  ?

  <module>
    <web>
      <web-uri>bnnp-ui-1.0-SNAPSHOT.war</web-uri>
      <context-root>/BNNP-QA</context-root>
    </web>
  </module>

  <module>
    <web>
      <web-uri>bnnp-mobile-ui-1.0-SNAPSHOT.war</web-uri>
      <context-root>/BNNP-QA/MOBILE</context-root>
    </web>
  </module>

</application>

Show
The workaround is to reduce 3 apps into two: merge the first two, like below: <?xml version="1.0" encoding="UTF-8"?> <application xmlns=" http://java.sun.com/xml/ns/j2ee " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " xsi:schemaLocation=" http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd " version="1.4">   <description>BNNP ear</description>   <display-name>bnnp-ear</display-name>   <!?Move the filter into the second app, I guess ICEFaces does not support sub context redirect   <module>     <web>       <web-uri>url-filter-1.0-SNAPSHOT.war</web-uri>       <context-root>/BNNP-QA</context-root>     </web>   </module>   ?   <module>     <web>       <web-uri>bnnp-ui-1.0-SNAPSHOT.war</web-uri>       <context-root>/BNNP-QA</context-root>     </web>   </module>   <module>     <web>       <web-uri>bnnp-mobile-ui-1.0-SNAPSHOT.war</web-uri>       <context-root>/BNNP-QA/MOBILE</context-root>     </web>   </module> </application>

Description

Basically we have one EAR file, the structure is like below:

<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd" version="1.4">
  <description>BNNP ear</description>
  <display-name>bnnp-ear</display-name>

  <module>
    <web>
      <web-uri>url-filter-1.0-SNAPSHOT.war</web-uri>
      <context-root>/BNNP-QA</context-root>
    </web>
  </module>

  <module>
    <web>
      <web-uri>bnnp-ui-1.0-SNAPSHOT.war</web-uri>
      <context-root>/BNNP-QA/DESKTOP</context-root>
    </web>
  </module>

  <module>
    <web>
      <web-uri>bnnp-mobile-ui-1.0-SNAPSHOT.war</web-uri>
      <context-root>/BNNP-QA/MOBILE</context-root>
    </web>
  </module>

</application>

The url-filter application will decide where to redirect the incoming http request based on the user-agent http header. If it is from a handheld device, it will redirect to /BNNP-QA/MOBILE, otherwise to /BNNP-QA/DESKTOP. Of these, only the desktop application is using the ICEFaces framework. Now the problem is that for some reason, when the iced2d.js javascript posts the request to the ICEFaces block servlet when the page is loaded, it removes the "/" between BNNP-QA and DESKTOP, so that the context root becomes /BNNP-QADESKTOP which is obviously wrong and subsequently causes a "Network Connection Interrupted" every 3 minutes.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Tyler Johnson added a comment - 20/Mar/09 3:48 PM

Another customer is facing this same issue.

If they deploy their ICEFaces application with a sub context root, the second slash is removed and they receive "Network Connection Interrupted" warnings in the browser as well as server push failing to work. For example, if their context root is myApp/SubContext, they see the following in firebug:

POST
http://locahost:8080/myAppSubContext/block/receive-updated-views 404 Not Found 28ms

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /myAppSubContext/block/receive-updated-views was not found on this server.<P> <HR> <ADDRESS>Oracle-Application-Server-10g/10.1.3.4.0 Oracle-HTTP-Server Server at .........</ADDRESS> </BODY></HTML>

Show

Tyler Johnson added a comment - 20/Mar/09 3:48 PM Another customer is facing this same issue. If they deploy their ICEFaces application with a sub context root, the second slash is removed and they receive "Network Connection Interrupted" warnings in the browser as well as server push failing to work. For example, if their context root is myApp/SubContext, they see the following in firebug: POST http://locahost:8080/myAppSubContext/block/receive-updated-views 404 Not Found 28ms <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>404 Not Found</TITLE> </HEAD><BODY> <H1>Not Found</H1> The requested URL /myAppSubContext/block/receive-updated-views was not found on this server.<P> <HR> <ADDRESS>Oracle-Application-Server-10g/10.1.3.4.0 Oracle-HTTP-Server Server at .........</ADDRESS> </BODY></HTML>

Hide

Permalink

Deryk Sinotte added a comment - 26/Mar/09 1:34 PM

So my test application half works. It appears that only a couple of the bridge communication functions are affected - recieve-updated-views and dispose-views.

The guilty party seems to be in DOMResponseWriter where we figure out all the various URL information to configure the bridge's communication info. In the enhanceBody() method, there is this bit of logic:

String contextPath = handler.getResourceURL(context, "/");
if (blockingRequestHandlerContext == null)

{ blockingRequestHandlerContext = URI.create("/").resolve(contextPath.replaceAll("/", "") + "/").toString(); }

Taking out the bit about .replaceAll("/", "") seems to fix the problem in my test case for both of the malfunctioning requests. Just need to see what, if any, is the historical reason for removing the slashes in the first place.

Show

Deryk Sinotte added a comment - 26/Mar/09 1:34 PM So my test application half works. It appears that only a couple of the bridge communication functions are affected - recieve-updated-views and dispose-views. The guilty party seems to be in DOMResponseWriter where we figure out all the various URL information to configure the bridge's communication info. In the enhanceBody() method, there is this bit of logic: String contextPath = handler.getResourceURL(context, "/"); if (blockingRequestHandlerContext == null) { blockingRequestHandlerContext = URI.create("/").resolve(contextPath.replaceAll("/", "") + "/").toString(); } Taking out the bit about .replaceAll("/", "") seems to fix the problem in my test case for both of the malfunctioning requests. Just need to see what, if any, is the historical reason for removing the slashes in the first place.

Hide

Permalink

Deryk Sinotte added a comment - 26/Mar/09 5:56 PM

I checked in a new algorithm for massaging the contextPath so that slashes were only removed from the beginning and end but not the middle.

Show

Deryk Sinotte added a comment - 26/Mar/09 5:56 PM I checked in a new algorithm for massaging the contextPath so that slashes were only removed from the beginning and end but not the middle.

ICEfaces does not support sub context redirect

Details

Description

Activity

People

Dates