Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
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
-
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.
Attachments
-
- layout.jsp
- 05/May/11 8:05 AM
- 0.3 kB
- Roger de la Fuente
-
- layout-tstone.jsp
- 05/May/11 2:26 PM
- 0.5 kB
- Timothy Stone
-
- test.jsp
- 05/May/11 8:05 AM
- 0.3 kB
- Roger de la Fuente
-
- test-tstone.jsp
- 05/May/11 2:26 PM
- 0.3 kB
- Timothy Stone
-
$i18n.getText("admin.common.words.hide")
- wls-stripes-bug.war
- 25/May/11 3:54 PM
- 541 kB
- Timothy Stone
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.1 kB
- index.jsp 0.4 kB
- WEB-INF/lib/commons-logging-1.1.1.jar 59 kB
- WEB-INF/lib/stripes-1.5.6.jar 525 kB
- WEB-INF/web.xml 0.7 kB
- WEB-INF/view/render.jsp 0.3 kB
- WEB-INF/view/layout.jsp 0.5 kB
- META-INF/maven/.../wls-stripes-bug/pom.xml 2 kB
- META-INF/maven/.../pom.properties 0.1 kB
-
$i18n.getText("admin.common.words.hide")
- wls-stripes-bug-1.0-SNAPSHOT.war
- 27/May/11 9:57 PM
- 543 kB
- Timothy Stone
-
- META-INF/MANIFEST.MF 0.1 kB
- META-INF/context.xml 0.0 kB
- index.jsp 0.4 kB
- WEB-INF/lib/commons-logging-1.1.1.jar 59 kB
- WEB-INF/lib/stripes-1.5.6.jar 525 kB
- WEB-INF/weblogic.xml 0.3 kB
- WEB-INF/web.xml 3 kB
- WEB-INF/.../LayoutTestActionBean.class 1 kB
- WEB-INF/.../LayoutTestActionBean.class 1 kB
- WEB-INF/view/render.jsp 0.3 kB
- WEB-INF/view/layout.jsp 0.7 kB
- META-INF/maven/.../wls-stripes-bug/pom.xml 2 kB
- META-INF/maven/.../pom.properties 0.1 kB
$i18n.getText("admin.common.words.show")- wls-stripes-bug-1.0-SNAPSHOT.war
- 27/May/11 9:57 PM
- 543 kB
- Timothy Stone
-
$i18n.getText("admin.common.words.hide")
- wls-stripes-bug-1.0-SNAPSHOT.war
- 25/May/11 5:02 PM
- 542 kB
- Timothy Stone
-
- META-INF/MANIFEST.MF 0.1 kB
- index.jsp 0.4 kB
- META-INF/context.xml 0.0 kB
- WEB-INF/.../LayoutTestActionBean.class 1 kB
- WEB-INF/lib/commons-logging-1.1.1.jar 59 kB
- WEB-INF/lib/stripes-1.5.6.jar 525 kB
- WEB-INF/view/layout.jsp 0.7 kB
- WEB-INF/view/render.jsp 0.3 kB
- WEB-INF/web.xml 3 kB
- META-INF/maven/.../wls-stripes-bug/pom.xml 2 kB
- META-INF/maven/.../pom.properties 0.1 kB
$i18n.getText("admin.common.words.show")- wls-stripes-bug-1.0-SNAPSHOT.war
- 25/May/11 5:02 PM
- 542 kB
- Timothy Stone
Activity
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.
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.
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.
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.
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" %>
The previously attached WAR was bad. This WAR corrects.
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.
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.
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.
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
@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[] ?
The code just abuses the Servlet API. It doesn't get down to the level of messing with character encoding.
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.
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.
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.
Reopening so I can change the resolution to fixed.
My test files show something very similar.