Stripes

I tried the stripes-example on both weblogic 10.0.3.2 as 10.0.3.4 and it suffers from the same issue as the cloned issue.

When the stripes jar (currently 1.5.6) is replaced by stripes-1.5.3.jar the stripes-example works (is rendered correctly)

This issue is blocking development on weblogic (with the newest version).

I tried both adding a weblogic.xml file which I extracted from the cloned issue as setting the content type encoding as proposed in the former ticket.

br,

Sander

I integrated bugzooki into the large project it will be a part of and it failed building, until I adapted the version of java compilation from 1.5 to 1.6,

the stripes.jar is now version 1.5.6, the tags:
<%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8"%>

are placed and this all seemed to do the trick;
the weblogic.xml I didn't copy so that might also work...

S.

Can you clarify that last part... did you say you recompiled the Stripes JAR against 1.6? or are you saying that you're executing your project against the 1.6 JDK (I thought that JRockit in 10.3.3.0 was 1.6.0_15-ish).

Also clarify your WLS versions, I suspect you mean 10.3.2.0 and 10.3.4.0, not 10.0.3.x as noted above.

I have an open ticket with Oracle, SR 3-3688679421. Oracle has not closed it but wants me to reimplement an API to prove something, but I haven't had time to do so, copied below:

"I was looking to get more information from engineering on this, but off-hand it was not clear what the issue might be, and from what we have found so far they did not believe it necessarily point to a problem in Weblogic. So it is doubtful they will accept a bug to investigate. Continue forward from a Weblogic perspective, we may need to figure out how to debug further. This of course, unfortunately, is not a simple task. What would be ideal is to replicate the issue without Stripes. Does your team think it might be possible to replicate with the basic Java functionality without Stripes( e.g. RequestDispatcher#include)? Any further updates from your findings?"

The Oracle engineers are not likely to investigate further at this time, if only because it seems to be a Stripes issue. I'm on the side of the fence that this is not Stripes but some WLS default that is not obvious. Especially since the problem is not exhibited in GlasshFish, Tomcat, or Resin.

I'm not sure that replicating the RequestDispatcher#include outside of Stripes would be an easy task.

It's possible that the suggested fix found in the weblogic.xml for us works because we compile our project against 1.6. That's an interesting finding. It could possibly point to a clue to the source of the problem.

–
Please vote 'YES" on STS-833.

I rebuild stripes-example against jdk 1.6
(in the stripes-example's build.xml I changed this line:
<javac target="1.6" destdir="${classes.dir}" debug="on">
normally it is set to 1.5.)

The rest of the project has target 1.6 so I rebuild the war with target 1.6,
I left the stripes jar's untouched.

I indeed set the versions of weblogic wrong; both 10.3.4.0 and 10.3.2.0 suffered from the issue and in both servers the problem seems resolved.

About the weblogic.xml:
it is not present in the war which works,
in fact, there is no weblogic.xml present in that war so that couldn't solve the problem;

so only adding the utf-8 tags and changing the target to 1.6 solve the issue (for stripes-example; I didn't got the war of the original bug to work(even not in tomcat, I believe...)
no need for the weblogic.xml for solving that problem.

I hope you have enough information.

In the end, all I really did was downloading the example; add the tags; change the target and it works...

If you need further info, just ask

br,

S.

Thanks Sander.

I'm looking at the Stripes Example app now. Did you add the page directive to the Quickstart? Bugzooky? If you removed the page directive, does the problem reappear? (I believe it will). And leaving the page directive out but copying the weblogic.xml from STS-823 with the <encoding> attribute present, does the problem disappear? (I believe it will).

I would do all this myself, but my WebLogic install is not quite stable today.

It's the bugzooky application which I used and didn't work.

-> if I leave out the page directive it doesn't work anymore (this was the starting situation)
-> if I leave out the page directive and put the weblogic.xml from the example the problem doesn't disappear!!

S.

Something that will definitely interest you:

if I put the page directive and bake in the weblogic.xml from the cloned bug solution the application does not work as it is supposed to,
(same defect)

when I leave the page directive in and remove the weblogic.xml it works,

I guess that's something you might find useful in finding the cause of the behavior,

I made a separate project for the example where I can experiment on if you want me to do changes,
and can always deploy stuff on the weblogic which suffers from the original defect,
probably until you know what is going wrong and hopefully get a fix

since I'm deblocked on the issue and I'm not a stripes developer but a stripes user I can help you with testing but developing on stripes is not my ambition

grtz,

S.

I'm running into the same issue.

I am running WLS 10.3.3.0 on Windows 7.

I've tried the solution in SFS-823 (wls-stripes-bug-1.0-SNAPSHOT.war) and It didn't work for me.

Has there been any movement on this issue?

I've also tested this issue with WLS 10.3.5 and its also a problem there.

I've figured out the work around.

Add :

<%@page contentType="text/html" pageEncoding="UTF-8"%>

to each layout JSP. DON'T add it to child pages that use the layouts, this will break it.

The main issue is when you include a JSP to a layout that has the pageEncoding defined you don't remove it and its wrong to change the pageEncoding 1/2 way through a page.

However, if you add a child page via <JSP:INCLUDE> it works as expected even if you define a pageEncoding in the child page.

Solution:

Check to see if child JSP has a pageEncoding, if so then remove it in the tag?

I have several applications written in Stripes, all with stripes v1.5.3 and Java 1.5. Works great on WebSphere(v 6.1.0.0), Oracle Application Server (v10.1.3.1.0) and from oc4j application server embeded in JDeveloper 10. I have tried to upgrade stripes to 1.5.4, 1.5.5 or 1.5.6 and in all 3 versions the JSPs with layout doesn't work. I don't have any runtime error, just the page is not rendered.

WebLogic closed my SR, SR 3-3688679421.

However, I stand by my finding that the issue appears to be with WebLogic seeking a hint with the page encoding.

I can report that v1.5.6 works in WebLogic 10.3.3.0 after setting the page encoding in the jsp descriptor, as I noted earlier in STS-823. We had the same problems every one is reporting. After some research, we added the jsp-descriptor and it solved the problem; no page directives, just the jsp-descriptor.

We are doing at least one thing that might be "helping" WebLogic a bit more:

Our POM explicitly declares the project encoding as UTF-8, <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

Maybe this helps our fairly standard, text book, use of Stripes Layouts.

We have dived into the generated source and found some clever optimizations, but nothing that seemed to scream a WebLogic or Stripes fault. Ben reports the Layout refactoring "abuses the JSP APIs," nothing more.

If there is a WebLogic fault it may be something in changes to the platform defaults that certain switches seem to control, but the WebLogic tech I worked with tried a number of things, including "honoring WEB-INF jars over WLS classpaths," etc.

I can see if Oracle will reopen the ticket, but it's doubtful. If any of you have Oracle support contracts, consider opening a ticket. Cite SR 3-3688679421, STS-823 and this one. My tech raised it to the "engineering level" but it went no where after at least a cursory review by said engineers, citing no support for third party JARs, etc.

Maybe more customers seeing a problem will move the issue to engineering.

I have created a Mavenized WAR that deploys to WebLogic 10.3.5 and works as intended.

You can clone the git repos at github with the following:

% git clone git://github.com/timothystone/Stripes-on-WebLogic-10.3.x.git
% mvn clean package

Then via the Admin console, deploy.

It's a rather simple web app, but demonstrates the original layout.jsp and render.jsp files with a layout-component being called to override the default value text, as originally seen STS-823.

Some notes:

1. project.build.sourceEncoding is set to UTF-8 in the pom.xml properties stanza
2. target is 1.6
3. weblogic.xml jsp-descriptor sets the encoding to UTF-8
4. NO page directive is set on any JSP
5. The test platform prior to pushing to github is: Fedora 15, JDK 1.6.0_29 (not JRockit), WebLogic 10.3.5.0

It's git, so fork and push.

...

Vote YES on STS-833.

Changeset: e66334d0df5c12853d74344be3b7a858b450730d
Author: Timothy Stone
Date: 2011-11-08 11:46
Message: Updated specification versions for WLS 10.3.5

Has any more progress been made on this bug? I am having rendering problems with my layout-component's.
My testing is with WebLogic 10.3.5 on Xubuntu (Linux 3.0.0-15-generic) using Oracle JDK 1.6.0_29 and Stripes 1.5.6.
I have tried the following things:
-Using the page directive (<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>) in my base layout-definition
-Using the page directive in each JSP with my layout-render tags
-Adding the jsp-descriptor encoding UTF-8 in the weblogic.xml
-Adding the jsp-config jsp-property-group url-pattern=*.jsp and page-encoding=UTF-8 in the web.xml

Using the page directive in my base layout-definition partially works, but not all of my layout-component's get rendered properly, the other items had no effect.

I downloaded, built, and ran Timothy Stone's wls-stripes-bug-1.0-SNAPSHOT.war on my server, and it did not appear to work as I expected. When I ran it this is the browser page source of the "LayoutTest.action" page:

<stripes:layout-render name="/WEB-INF/view/layout.jsp" title="[WebLogic Test]">
<stripes:layout-component name="testing">
<p>Nice Component!</p>
</stripes:layout-component>
</stripes:layout-render>

I would not expect to see the stripes related tags as well as the page is missing the enclosing layout-definition from the layout.jsp which includes the html tag, body tag, and "Hello, nice body!" text.

I tried using the stripes-1.5.7-SNAPSHOT.jar from December 2, 2011, and all of my Stripes TLD tags are rendered as text, I am unsure of why this happened. I replaced my 1.5.6 jar with the 1.5.7 snapshot jar, and nothing else. All of the testing I described above is using the 1.5.6 jar.

I had previously used Glassfish without any problems, but due to a hosting change now must use Weblogic 10.3.5, any help would be greatly appreciated.

Seriously poorly tested code! I apologize. I didn't push the correction. Watch this space for an update.

BTW... i declare a tag prefix as one thing, and used another. that's why it behaves that way for you J.

Timothy,
Thank you for the quick response!
I changed the tag prefixes as you suggested and now when I click the "Let's do a component" link I get the following browser page source:

[WebLogic Test]

If my understanding is correct I should see something like:

<html><head><title>[WebLogic Test]</title></head><body><p>Hello, nice body!</p><p>Nice Component!</p></body></html>

I am very willing to do any testing you may need, please let me know if I can help in any way.

That's the error state. [Weblogic Test] should be in the title element.

So, WLS 10.3.5, Sun/Oracle JDK, and Stripes 1.5.6.

I'm on 10.3.2 here and can't dupe with my corrected build. There's must be something in WLS between patches, libs or something more subtle and nefarious that cause this problem. It can't be duplicated in Resin or Jetty either (though I have not recently tried either). Can you try setting: prefer-web-inf-classes in the provided weblogic.xml to try and isolate some WLS configuration you might have (if this is not a fresh build/domain)?

The <prefer-web-inf-classes> element, if set to true, will cause classes located in the WEB-INF directory of a Web application to be loaded in preference to classes loaded in the application or system classloader. The default value is false. A value specified in the console will take precedence over a value set manually.

In the history of this issue, I've seen varied results. I'm really wondering if it's something about WLS distros across platforms, or those tweaks admins do that go undocumented.

Added to the weblogic.xml:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>

The result is the same as my previous post. My Weblogic domain is fresh, except for a data source defined, some new users, and new groups in the default security realm.

I just installed Weblogic 10.3.2, using Sun/Oracle JDK 1.6.0_29, fresh domain, and auto deployed the modified wls-stripes-bug-1.0-SNAPSHOT.war, with the same result.

in IE and Firefox:
[WebLogic Test]

The only changes I made to the project was to replace all JSP instances of '<stripes:' with '<s:' and to add the prefer-web-inf-classes=true entry to the weblogic.xml.

Do you believe it is possibly my JDK version, or Xubuntu? Are there any Weblogic server settings that could help?

It's really hard to say what it is. I've been trying to do something different today: get Tomcat to behave as you're experiencing it. Basically, I can't.

I've also been looking at some other ideas: get weblogic to use the same superclass as Tomcat for JSP pages, org.apache.jasper.runtime.HttpJspBase (supposedly possible, but the documentation in 10.3 is sparse or warns of deprecation). Maybe the <%@ page extends %> directive?

A fresh set of eyes such as yours is always helpful.

Can you add the below directives to the weblogic.xml:

<working-dir>/path/to/someplace/convenient/and/accessible</working-dir>
<keepgenerated>true</keepgenerated>

I have the Tomcat generated servlet. I would like to get some more eyes on them to look at what WLS might be doing that is different.

Using Weblogic 10.3.2, Sun JDK 1.6.0_29, Xubuntu.
I created the workdir, added the following entry to the weblogic.xml, rebuilt with maven, and deployed.

<jsp-descriptor>
<keepgenerated>true</keepgenerated>
<working-dir>/my/path/wls1032/domains/domain1/workdir</working-dir>
</jsp-descriptor>

The behavior of the LayoutTest.action is the same as before, and no files were created in the 'workdir'. I attempted to find any of the files that the keepgenerated=true would have created, but was unsuccessful. My log output was as follows:

<Feb 2, 2012 9:58:50 AM EST> <Warning> <HTTP> <BEA-101369> <ServletContext@16458135[app:_appsdir_wls-stripes-bug-1.0-SNAPSHOT_war module:wls-stripes-bug-1.0-SNAPSHOT.war path:/wls-stripes spec-version:2.5]: The encoding jsp-descriptor param has been deprecated. Consider declaring the encoding in the jsp-config element (web.xml) or as a page directive (pageEncoding) instead.>
Feb 2, 2012 9:58:50 AM net.sourceforge.stripes.util.Log info
INFO: Using VFS adapter net.sourceforge.stripes.vfs.DefaultVFS
Feb 2, 2012 9:58:50 AM net.sourceforge.stripes.util.Log info
INFO: No locale list specified, defaulting to single locale: en_US
Feb 2, 2012 9:58:50 AM net.sourceforge.stripes.util.Log warn
WARNING: No MultipartWrapper implementation could be loaded
Feb 2, 2012 9:58:50 AM net.sourceforge.stripes.util.Log info
INFO: Stripes Initialization Complete. Version: 1.5.6, Build: 1.5.6

I ran the test again, this is my full weblogic.xml:

<?xml version="1.0" encoding="UTF-8"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
<context-root>/wls-stripes</context-root>
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
<jsp-descriptor>
<keepgenerated>true</keepgenerated>
<working-dir>/my/path/opt/wls1032/domains/domain1/workdir</working-dir>
<verbose>true</verbose>
<encoding>UTF-8</encoding>
</jsp-descriptor>
</weblogic-web-app>

These logs were generated in the AdminServer.log:

####<Feb 2, 2012 10:23:17 AM EST> <Info> <Deployer> <AdminServer> <[STANDBY] ExecuteThread: '5' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1328196197135> <BEA-149074> <Successfully completed deployment task: [Deployer:149026]deploy application _appsdir_wls-stripes-bug-1.0-SNAPSHOT_war on AdminServer.>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216851> <BEA-000000> <JspServlet: param verbose initialized to: true>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216852> <BEA-000000> <JspServlet: param packagePrefix initialized to: jsp_servlet>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216852> <BEA-000000> <JspServlet: param compilerclass initialized to: null>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216852> <BEA-000000> <JspServlet: param compileCommand initialized to: javac>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216852> <BEA-000000> <JspServlet: param compilerval initialized to: javac>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216852> <BEA-000000> <JspServlet: param pageCheckSeconds initialized to: 1>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216852> <BEA-000000> <JspServlet: param encoding initialized to: UTF-8>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216853> <BEA-000000> <JspServlet: param superclass initialized to null>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216853> <BEA-000000> <JspServlet: param workingDir initialized to: /home/jesse/opt/wls1032/domains/domain1/workdir>
####<Feb 2, 2012 10:23:36 AM EST> <Info> <ServletContext-/wls-stripes> <AdminServer> <[ACTIVE] ExecuteThread: '2' for queue: 'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <> <> <1328196216853> <BEA-000000> <JspServlet: initialization complete>

And the Eclipse console generated the same log messages as the previous comment.

J, let's take this off thread. Ping me on the IRC channel, or via github.

Updated the github project to correct a stripes tag prefix problem. commented the weblogic.xml a bit and add a jsp property config to the web.xml. Also made the error condition a little easier to grok.

Ben Gunter has provided a new TLD for buffered layout tags. In examining the issue, Ben was able to determine that WebLogic 10.3.x is not supporting the newer "streaming" layout tags.

A new "stripes-buffered-layout.tld" is provided in the newest 1.5.7-SNAPSHOT builds to address this incompatibility in WebLogic.

The new buffered layout tags essentially bring back features in the layout tags found in Stripes 1.5.3.

github test build has been updated. All encoding "hacks" are commented out. Support for both 1.5.7-SNAPSHOT and 1.5.6 is present in the POM and the JSPs.

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.

Hi, I have the same problem, now I use the Stripes 1.5.7 and WebLogic 10.3.5(I also try v10.3.6) under Jdeveloper 11g R2
I have the page tags in my jsp masterpage and it work fine. But when the size increase of my jsp, which use masterpage with layout (Ex. I use a lot of сyrillic symbol, I try 16kb) I haven't any error, just the page is not rendered and the java process up to 50% of processor usage.

Does this mean that I have to remove layoutof my app, if i use weblogic 10.3.x? Or is there a solution?