I'm afraid Nick is right, the layout don't render correctly.
Just checked my pages with a multi column layouts and they don't render
correctly in beta release 1257. The nested body that is in all super
templates does render, but the components in this body with other names
do not render. Don’t
Pre-build Stripes 1.5.4 (R1257) can be downloaded here:
http://kdeveloper.com/stripes-1-5-4-beta/
On 11-06-10 22:40, Nick Stuart wrote:
> Sorry I'm late to this party but just did some quick testing and there is one
> more functional change to be aware of. Following layout:
>
>
>
>
>
Sorry I'm late to this party but just did some quick testing and there is one
more functional change to be aware of. Following layout:
With 1.5.3 if rendered a page with:
my content here
It would get rendered as expected. with 1.5.x it does n
Personally, I've never found the dual nature of
confusing. Maybe that's just me. Whatever the case, adding a new tag isn't
an option for 1.5.4 because it's not backward-compatible. And after all the
work I've put in to get this streaming stuff working, I'm not interested in
yet another overhaul. I
"Anytime you reference a layout component in EL (e.g., ${body} as in
your sample files) then that component has to be evaluated and buffered
as a string."
OK, sounds logical.
But why use EL if it stops the layout from streaming? I know it's the
only way to reference a layout-component from the
Great to hear the layouts are rendering properly for you now. The goal was
to make them behave as closely as possible to the 1.5.3 release. The new
code does behave a little differently from 1.5.3 in some cases, but I think
those differences are actually improvements over the last release. I know
t
Ben,
The Stripes 1.5.4 beta R1252 seems to render the layouts in my projects
just as the 1.5.3 release version. I will do some more checks later this
week.
Do these layout now render directly to the servlet output stream?
-Karen
On 08-06-10 0:09, kdeveloper wrote:
>
> Pre-build Stripes 1.5.4
Pre-build Stripes 1.5.4 (R1252) can be downloaded here:
http://kdeveloper.com/stripes-1-5-4-beta/
On 07-06-10 22:53, Ben Gunter wrote:
> I believe this is fixed with my most recent commit. Everybody please
> test out the latest 1.5.x branch and let me know how it goes.
>
> -Ben
>
> On Mon, Jun
I believe this is fixed with my most recent commit. Everybody please test
out the latest 1.5.x branch and let me know how it goes.
-Ben
On Mon, Jun 7, 2010 at 8:44 AM, Ben Gunter wrote:
> Excellent, thank you. I'll do some testing/bug hunting with these and get
> back to you.
>
> -Ben
>
>
> On
Excellent, thank you. I'll do some testing/bug hunting with these and get
back to you.
-Ben
On Mon, Jun 7, 2010 at 8:31 AM, kdeveloper wrote:
> Ben,
>
> I've made as simple as possible JSP files that can reproduce the layout
> rendering problem in Stripes 1.5.4 beta (R1250). The three layers of
Ben,
I've made as simple as possible JSP files that can reproduce the layout
rendering problem in Stripes 1.5.4 beta (R1250). The three layers of
layout's seems crucial in reproducing the failure.
testPage.jsp:
<%...@taglib prefix="s" uri="http://stripes.sourceforge.net/stripes.tld"; %>
[tes
Ben,
I think I found the reason why my layouts don't work under 1.5.4 beta.
I have nested layout’s that all use the same component name. Beta does
not seem to like that I have a ‘basePage.jsp’ layout defenition with a
component name “body” that is used by a ‘threeColumnPage.jsp’ layout
definit
Ben,
Just returned from a short trip and did a quick test run on my project.
Unfortunately my layouts did not render correctly. I still get the same
stack overflow errors and out of order layouts.
I will try to isolate the problem this week and send you some source file's
that can reproduce th
I've build the current 1.5.x branch (Revision 1250) and made it available
for download here:
http://kdeveloper.com/stripes-1-5-4-beta/
Please all, test this version.
"Ben Gunter" wrote in
message news:aanlktik7ww2avln-rstahrkcetumj_lrhe17ok7e-...@mail.gmail.com...
>I have checked in a whole bu
I have checked in a whole bunch of improvements in the last few days. I did
my best using the snippets you sent to reconstruct your layout for testing,
and it looks to me like it works. (At least my reconstructed version does.)
I haven't got the POM issues resolved yet so you'll need to build with
Richard,
It's great to see that the latest 1.5.x code appears to have resolve
your issue.
However, I wonder if your issue occurs in web containers other than
Tomcat. I found this interesting thread:
Source: http://www.mail-archive.com/d...@tomcat.apache.org/msg05273.html
BodyContentImpls
Mortan,
I'm using the following settings for tomcat:
CATALINA_OPTS='-Djava.awt.headless=true -Dserver.info=IIS -server
-Xmx128M -Xms80M -XX:MaxPermSize=60M -XX:PermSize=30M'
#MemoryLeakPrecausions
CATALINA_OPTS="$CATALINA_OPTS
-Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true
-Dorg.ap
Hi all
Thanks a lot for your efforts.
To test these suggestions please advise on the best possible JVM settings.
Regards
Morten Matras
2010/5/20 Richard Hauswald
> Hi folks
> thanks for all the input and effort you put in this issue. Thanks for
> the jar package. Tested it yesterday and all
Hi folks
thanks for all the input and effort you put in this issue. Thanks for
the jar package. Tested it yesterday and all the memory issues are
gone. The memory consumption is optimized by factor 7 in my case! User
experience is also much better now since layouts are streamed. Ben,
thankz for the
Ben,
Thanks for all the work!
I'm running this in Tomcat (Windows XP). The info.jsp works fine under
Stripes-1.5.3 but result in an infinite loop when used with
Strips-1.5.4-beta (Revision: 1236).
-
These are the errors in the Tomcat log fil
I'd like to see some layouts that trigger this behavior. I tested many
different cases, including components out of order, and haven't seen any of
these kinds of problems. What container are you testing on?
-Ben
On Wed, May 19, 2010 at 11:22 AM, KR wrote:
> I've build the current 1.5.x branch (
I've build the current 1.5.x branch (Revision 1236) and made it available
for download here:
http://kdeveloper.com/stripes-1-5-4-beta/
I've also run it agains my current applications template and the current
beta does not seem to work correctly (or my templates need to be adjusted
for the new
I've built and run the 1.5.x branch against my applications ( Currently on
Stripes 1.5.3 ) running on Tomcat 5.5.27 & 6.0.26. I've run through a few
tests and they appear to be working great. I haven't taken a look at the
memory usage, but from the end user's perspective, all of our screens seem
to
I just committed the changes to the 1.5.x branch. I'd like this to undergo
some serious testing so anybody who is able, please build from SVN and test
in your existing applications or test setups. I've done some basic tests and
have tested it in my application, and it works really well for me. Let
Sorry to truncate your thorough response, but I just wanted to let anyone
who is interested know that I think I have managed to make the layout tags
stream output directly to the client instead of buffering it and then
dumping the whole thing at once. This should eliminate the possibility of a
memo
Richard (and Ben),
Appears like a lot of good work has gone into trying to resolve / fix
this
Thanks for the info. I hope my comments in-line can assist
--Nikolaos
Richard Hauswald wrote:
I spent some time investigating the problem - results:
Can you provide a little more infor
Richard, do you have any of these tests that could be fired up in other
containers? Would be willing to test in glassfish as we use that and have never
really experienced any memory issues from stripes. Our apps use a bit of
memory, but we've never gotten an exception from stripes being out of m
I spent some time investigating the problem - results:
- The problem is not related to thread locals.
- The memory costs using layout tag with ~2MB sized pages is
significant. Without layout tag the test (20 threads parallel same
page) took around 35MB, with layout tag around 190MB
- After this tes
I just applied it to the 1.5.x branch. There won't be anymore 1.4.x releases
so I'm not going to bother patching that branch. Richard indicated to me
yesterday (off list) that this patch didn't seem to help the situation for
him so don't expect much.
-Ben
On Wed, May 12, 2010 at 4:27 AM, M.C.S.
Hi Ben,
could you please check in the patch into the 1.5.x and, if needed, the
1.4.x branches? Currently we are not using the version on trunk, but
also would like to benefit from the fix asap.
Marcus
Am 11.05.2010 17:10, schrieb Ben Gunter:
> I did a little poking around and found that somet
I did a little poking around and found that sometime in 2008,
LayoutComponentTag was changed such that it does not null its reference to
its BodyContent. Apparently it had to do with a bug in Resin, but I suspect
it might have led to a memory leak. The JSP spec is clear that
setBodyContent is to be
Hey Ben,
I think there is leak even tag pooling is disabled. I am using the
current version of tomcat and disabled tag pooling. Did some other
modifications too so here is the sum:
CATALINA_OPTS='-Djava.awt.headless=true -Dserver.info=IIS -server
-Xmx100M -Xms80M -XX:MaxPermSize=60M -XX:PermSize=30
As far as I know, this is not a leak, per se. It is caused by tag pooling,
which is the container *intentionally* holding stuff in memory so it can be
reused instead of creating new objects each time they're needed. Containers
can be configured to disable tag pooling if it causes a problem.
I unde
Hello @all,
IMHO using stripes layout is a good thing - well if the tag will be
fixed to stream and the memory leak is removed :-) I don't think jsp
tag files should be used for as website templates / layout solution.
But they should be used for building components like buttons or modal
dialog scre
Nikolaos,
If you are using JSP as a view technology in an MVC pattern, then IMO you
should not want to use scriptlets in you're JSP. Because what ever you want
to do in a scriptlet is the responsibility of the controller a.k.a. Action
Bean. Seen this way, it's actually a good thing that JSP tag
Will,
Thanks for the input. This caught my attention about at least one
particular benefit of Stripes Layout over Tag Files:
http://www.stripesframework.org/display/stripes/Layout+Reuse
*Page fragment layouts
*
This might be obvious, but you can also use a layout to control how a
small piec
Nikolaos,
I can't comment on Stripes Layout memory consumption, nor the use of Tiles.
I can only follow up with what Richard said about JSP 2.0 Tag Files.
I've not used Tiles or Stripes Layout simply because Tag Files exist, and I use
those instead.
JSP Tag Files effectively are as memory effi
Richard,
Comments in-line...
Richard Hauswald wrote:
> Nikolaos,
> after reading the introduction of tiles I like to state out that jsp
> tag files(not jsp tags) are a standard compliant way to embed reusable
> content -
OK
> there is no need for another framework to solve a problem
> which is
Nikolaos,
after reading the introduction of tiles I like to state out that jsp
tag files(not jsp tags) are a standard compliant way to embed reusable
content - there is no need for another framework to solve a problem
which is already solved.
Also keep in mind that HTTP responses are streams, not
Hi,
I came across the following reported against 1.4.3:
http://www.stripesframework.org/jira/browse/STS-391
While I have used Tiles and am OK with it, Stripes Layout seems nice and
being built-in makes me lean toward it more.
However, this thread on Tiles being "less memory hungry" worries me.
40 matches
Mail list logo
