Stripes

Stripes Layouts not working in Weblogic 10.3.3.0

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: Release 1.5.4, Release 1.5.5, Release 1.5.6
  • Fix Version/s: Release 1.5.7
  • Component/s: Tag Library
  • Labels:
  • Environment:
    Tested on Windows XP and RHEL.
    Oracle Weblogic 10.3.3.0.
    Tried from Stripes 1.5.3 to 1.5.6

Description

Stripes layout capabilities are unable to render correctly a layout in Oracle Weblogic.

A simple test case has been tested in Weblogic under Windows and RHEL, both in WL 10.3.3.0 version, and in Glassfish.

It works perfectly in Glassfish, but won't work in WL. Seems that the problem is the call to pageContext.include, which Stripes makes, and doesn't result in the target JSP being included in the result.

I'm attaching the test jsp files. When accessing test.jsp it prints "Hello" on the screen, but doesn't print the "Default text", neither the "I'm here!" strings.

Both jsp are stored in the root of the WAR file being uploaded to the container.

  1. layout.jsp
    05/May/11 8:05 AM
    0.3 kB
    Roger de la Fuente
  2. layout-tstone.jsp
    05/May/11 2:26 PM
    0.5 kB
    Timothy Stone
  3. test.jsp
    05/May/11 8:05 AM
    0.3 kB
    Roger de la Fuente
  4. test-tstone.jsp
    05/May/11 2:26 PM
    0.3 kB
    Timothy Stone

Activity

Hide
Timothy Stone added a comment - 05/May/11 2:26 PM

My test files show something very similar.

Show
Timothy Stone added a comment - 05/May/11 2:26 PM My test files show something very similar.
Hide
Timothy Stone added a comment - 05/May/11 2:32 PM

My attached files show something very similar.

The output would be:

[Weblogic Test]/img/favicon.ico

and nothing else. "[WebLogic Test]' the result of the EL expression provided in the title attribute of test-tstone.jsp passed to the layout-definition of layout-tstone.jsp. Additionally of note, only the result of the customtag:resource (shown in the layout-tstone.jsp) "/img/favicon.ico" is put on the response. None of the HTML elements are on the response. Viewing source of the response is just: "[Weblogic Test]/img/favicon.ico", otherwise empty.

The customtag would have otherwise processed the string passed in the 'src' attribute shown and adjusted its path appropriately based on session variables after a login action.

Show
Timothy Stone added a comment - 05/May/11 2:32 PM My attached files show something very similar. The output would be: [Weblogic Test]/img/favicon.ico and nothing else. "[WebLogic Test]' the result of the EL expression provided in the title attribute of test-tstone.jsp passed to the layout-definition of layout-tstone.jsp. Additionally of note, only the result of the customtag:resource (shown in the layout-tstone.jsp) "/img/favicon.ico" is put on the response. None of the HTML elements are on the response. Viewing source of the response is just: "[Weblogic Test]/img/favicon.ico", otherwise empty. The customtag would have otherwise processed the string passed in the 'src' attribute shown and adjusted its path appropriately based on session variables after a login action.
Hide
Timothy Stone added a comment - 05/May/11 2:35 PM

BTW, I only see this problem with 1.5.4 – 1.5.7-SNAPSHOT. WebLogic 10.3.3 and Stripes 1.5.3 work fine.

Show
Timothy Stone added a comment - 05/May/11 2:35 PM BTW, I only see this problem with 1.5.4 – 1.5.7-SNAPSHOT. WebLogic 10.3.3 and Stripes 1.5.3 work fine.
Hide
Roger de la Fuente added a comment - 06/May/11 4:56 AM

Hi Timothy,

Yes, you are right. I had tried it on Stripes 1.5.3 (or at least that's what I thought). I tried again and it is working in 1.5.3. If someone could edit the issue to remove the 1.5.3 from affected versions would be great.

Since 1.5.3 is working and 1.5.4 is not, I'll try to see the diffs of relevant java source code to find the bug. I don't have much experience with JSP rendering and taglibs... but I'll learn on the way

I'll keep this thread updated with the results of my investigation.

Thanks.
Roger.

Show
Roger de la Fuente added a comment - 06/May/11 4:56 AM Hi Timothy, Yes, you are right. I had tried it on Stripes 1.5.3 (or at least that's what I thought). I tried again and it is working in 1.5.3. If someone could edit the issue to remove the 1.5.3 from affected versions would be great. Since 1.5.3 is working and 1.5.4 is not, I'll try to see the diffs of relevant java source code to find the bug. I don't have much experience with JSP rendering and taglibs... but I'll learn on the way I'll keep this thread updated with the results of my investigation. Thanks. Roger.
Hide
Timothy Stone added a comment - 06/May/11 5:46 AM

Removed 1.5.3 from the affected versions.

Show
Timothy Stone added a comment - 06/May/11 5:46 AM Removed 1.5.3 from the affected versions.
Hide
stripesuser added a comment - 17/May/11 6:44 AM

Hi Roger

I had the same problem.
After some investigations I found two things you can change and it should work:
1. The page directive should be the first line in your jsp files.
2. Change the page directive to <%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8"%>

Let me know if it solved the problem.

Show
stripesuser added a comment - 17/May/11 6:44 AM Hi Roger I had the same problem. After some investigations I found two things you can change and it should work: 1. The page directive should be the first line in your jsp files. 2. Change the page directive to <%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8"%> Let me know if it solved the problem.
Hide
Timothy Stone added a comment - 19/May/11 12:51 PM

stripesuser,

Interesting. What if page directives are not being used? We are not using any.

Of note is that the spec is pretty clear that contentType directives are the only exception to the position independent nature of page directives: <%@ page contentType="text/html" ... %> must appear on the first line of the document.

The "default," or unwritten, page directive for contentType is:

<%@page contentType="text/html;charset=UTF-8" pageEncoding="ISO-8859-1" language="java" %>

Show
Timothy Stone added a comment - 19/May/11 12:51 PM stripesuser, Interesting. What if page directives are not being used? We are not using any. Of note is that the spec is pretty clear that contentType directives are the only exception to the position independent nature of page directives: <%@ page contentType="text/html" ... %> must appear on the first line of the document. The "default," or unwritten, page directive for contentType is: <%@page contentType="text/html;charset=UTF-8" pageEncoding="ISO-8859-1" language="java" %>
Hide
Timothy Stone added a comment - 25/May/11 3:53 PM

Open a SR with Oracle. SR 3-3688679421

Show
Timothy Stone added a comment - 25/May/11 3:53 PM Open a SR with Oracle. SR 3-3688679421
Hide
Timothy Stone added a comment - 25/May/11 3:54 PM

Simple test case.

Show
Timothy Stone added a comment - 25/May/11 3:54 PM Simple test case.
Hide
Timothy Stone added a comment - 25/May/11 5:02 PM

The previously attached WAR was bad. This WAR corrects.

Show
Timothy Stone added a comment - 25/May/11 5:02 PM The previously attached WAR was bad. This WAR corrects.
Hide
Timothy Stone added a comment - 26/May/11 9:45 PM

Please set the <encoding> element of the <jsp-descriptor> of your weblogic.xml file to UTF-8 and validate.

weblogic.xml
...
<jsp-descriptor>
...
<encoding>UTF-8</encoding>
...
</jsp-descriptor>

Closing this issue.

Show
Timothy Stone added a comment - 26/May/11 9:45 PM Please set the <encoding> element of the <jsp-descriptor> of your weblogic.xml file to UTF-8 and validate. weblogic.xml ... <jsp-descriptor> ... <encoding>UTF-8</encoding> ... </jsp-descriptor> Closing this issue.
Hide
Timothy Stone added a comment - 26/May/11 9:53 PM

WebLogic will not properly handle encoding, possibly in nested custom tags throughout the tag lifecycle (though not entirely sure). Setting the WebLogic configuration to a specific JSP encoding corrects the problem.

Setting the <page-encoding> of the <jsp-property-group> of the web.xml has no effect and this might be an off-spec implementation. However, the weblogic.xml supports an default JSP encoding in the proprietary <jsp-descriptor> element: <encoding>.

<jsp-descriptor>
...
<encoding>UTF-8</encoding>
...
</jsp-descriptor>

It is unclear how the Layout refactoring may have contributed, requiring the setting of the <encoding> element.

Show
Timothy Stone added a comment - 26/May/11 9:53 PM WebLogic will not properly handle encoding, possibly in nested custom tags throughout the tag lifecycle (though not entirely sure). Setting the WebLogic configuration to a specific JSP encoding corrects the problem. Setting the <page-encoding> of the <jsp-property-group> of the web.xml has no effect and this might be an off-spec implementation. However, the weblogic.xml supports an default JSP encoding in the proprietary <jsp-descriptor> element: <encoding>. <jsp-descriptor> ... <encoding>UTF-8</encoding> ... </jsp-descriptor> It is unclear how the Layout refactoring may have contributed, requiring the setting of the <encoding> element.
Hide
Roger de la Fuente added a comment - 27/May/11 1:37 AM

I've tried both solutions, but it didn't fix it. Neither putting that directive in the top of the JSPs, nor including the jsp-descriptor section in the weblogic.xml file solved the issue. Still trying to understand what changed from 1.5.3 to 1.5.4 to make it stop working... I haven't had the time yet, but I will do that diff and check where the problem could be.

Thanks.

Show
Roger de la Fuente added a comment - 27/May/11 1:37 AM I've tried both solutions, but it didn't fix it. Neither putting that directive in the top of the JSPs, nor including the jsp-descriptor section in the weblogic.xml file solved the issue. Still trying to understand what changed from 1.5.3 to 1.5.4 to make it stop working... I haven't had the time yet, but I will do that diff and check where the problem could be. Thanks.
Hide
Ben Gunter added a comment - 27/May/11 7:21 AM

A whole lot changed from 1.5.3 to 1.5.4 to improve the performance of the layout tags. There was a follow-up from Tim Stone on the stripes-development list to your comment above. It's pasted below in case you aren't subscribed.

===

Roger,

In debugging this with ORCL and others we noted that just updating the app would not reflect changes if the JSPs had not been touched, e.g.., `touch my.jsp`.

In the use of the page directive this happened automatically. In this use of <encoding> it did not.

Redeploying, WLS Delete and Install, would reflect changes.

That said, our tests were on 10.3.0.0. And now, I'm doubting our findings if a patch version like 10.3.3.0 exhibits different behavior.

I'll upload the WAR demonstrating the fix. Also, your app may be more "interesting" than the simple WAR being used.

Tim

Show
Ben Gunter added a comment - 27/May/11 7:21 AM A whole lot changed from 1.5.3 to 1.5.4 to improve the performance of the layout tags. There was a follow-up from Tim Stone on the stripes-development list to your comment above. It's pasted below in case you aren't subscribed. === Roger, In debugging this with ORCL and others we noted that just updating the app would not reflect changes if the JSPs had not been touched, e.g.., `touch my.jsp`. In the use of the page directive this happened automatically. In this use of <encoding> it did not. Redeploying, WLS Delete and Install, would reflect changes. That said, our tests were on 10.3.0.0. And now, I'm doubting our findings if a patch version like 10.3.3.0 exhibits different behavior. I'll upload the WAR demonstrating the fix. Also, your app may be more "interesting" than the simple WAR being used. Tim
Hide
Timothy Stone added a comment - 27/May/11 8:54 AM

@Roger... some platform notes in full disclosure of my resolution (I have not closed the issue fully yet). Are you on JRockit? Likely in the RHEL environment and Window dev environment, we are. However, my success was on the Sun/Oracle JDK on Mac OS X. I'm still awaiting ORCLs findings.

ORCL seems to think this is an encoding issue and looking at the generated servlets leans in this direction.

@Ben, can you think of changes in how the LayoutWriter introduced in 1.5.4 may play with the encoding of byte[] ?

Show
Timothy Stone added a comment - 27/May/11 8:54 AM @Roger... some platform notes in full disclosure of my resolution (I have not closed the issue fully yet). Are you on JRockit? Likely in the RHEL environment and Window dev environment, we are. However, my success was on the Sun/Oracle JDK on Mac OS X. I'm still awaiting ORCLs findings. ORCL seems to think this is an encoding issue and looking at the generated servlets leans in this direction. @Ben, can you think of changes in how the LayoutWriter introduced in 1.5.4 may play with the encoding of byte[] ?
Hide
Ben Gunter added a comment - 27/May/11 9:10 AM

The code just abuses the Servlet API. It doesn't get down to the level of messing with character encoding.

Show
Ben Gunter added a comment - 27/May/11 9:10 AM The code just abuses the Servlet API. It doesn't get down to the level of messing with character encoding.
Hide
Timothy Stone added a comment - 27/May/11 9:54 PM

On Linux x86 32-bit, Debian/Ubuntu 10.04 LTS, WLS 10.3.0.0 running JRockit 1.6.0_5 adding the <encoding> element to the <jsp-descriptor> works.

Attaching the WAR.

Show
Timothy Stone added a comment - 27/May/11 9:54 PM On Linux x86 32-bit, Debian/Ubuntu 10.04 LTS, WLS 10.3.0.0 running JRockit 1.6.0_5 adding the <encoding> element to the <jsp-descriptor> works. Attaching the WAR.
Hide
Timothy Stone added a comment - 27/May/11 9:57 PM

wls-stripes-bug-1.0-SNAPSHOT.war

simple test case showing the use of the <jsp-descriptor> <encoding> element.

On Debian/Ubuntu 10.04 LTS running Weblogic 10.3.0.0 on the JRockit JVM 1.6.0_5, this corrects the problem exhibited in this report.

Show
Timothy Stone added a comment - 27/May/11 9:57 PM wls-stripes-bug-1.0-SNAPSHOT.war simple test case showing the use of the <jsp-descriptor> <encoding> element. On Debian/Ubuntu 10.04 LTS running Weblogic 10.3.0.0 on the JRockit JVM 1.6.0_5, this corrects the problem exhibited in this report.
Hide
Ben Gunter added a comment - 09/Feb/12 1:51 PM

Hi, folks. I wanted to let you know that Timothy Stone, Rick Grashel and I have done a lot of research and testing to get to the root of this problem. We have determined that it is a bug in WebLogic that is triggered when a call to PageContext.pushBody(Writer) is followed by a call to PageContext.include(String, boolean). This sequence of calls is central to the functionality of the streaming layout tags, and so this bug completely breaks them. I have devised a workaround for this problem that is used automatically if the application is running under WebLogic. Long story short, streaming layout tags will work under WebLogic in Stripes 1.5.7. Timothy will follow up with Oracle in an attempt to get them to recognize and fix this bug.

Show
Ben Gunter added a comment - 09/Feb/12 1:51 PM Hi, folks. I wanted to let you know that Timothy Stone, Rick Grashel and I have done a lot of research and testing to get to the root of this problem. We have determined that it is a bug in WebLogic that is triggered when a call to PageContext.pushBody(Writer) is followed by a call to PageContext.include(String, boolean). This sequence of calls is central to the functionality of the streaming layout tags, and so this bug completely breaks them. I have devised a workaround for this problem that is used automatically if the application is running under WebLogic. Long story short, streaming layout tags will work under WebLogic in Stripes 1.5.7. Timothy will follow up with Oracle in an attempt to get them to recognize and fix this bug.
Hide
Ben Gunter added a comment - 09/Feb/12 1:51 PM

Reopening so I can change the resolution to fixed.

Show
Ben Gunter added a comment - 09/Feb/12 1:51 PM Reopening so I can change the resolution to fixed.

People

Vote (0)
Watch (4)

Dates

  • Created:
    05/May/11 8:05 AM
    Updated:
    09/Feb/12 1:51 PM
    Resolved:
    09/Feb/12 1:51 PM