You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-user@tomcat.apache.org by Matt Raible <ma...@raibledesigns.com> on 2002/03/22 05:49:23 UTC
Can you test for a cookie's value using c:if tag?
Is it possible to do the following with JSTL?
<c:if test="${cookie.username == 'learner'}">
learner
</c:if>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Can you test for a cookie's value using c:if tag?
Posted by Shawn Bayern <ba...@essentially.net>.
On 29 Mar 2002, David M. Karr wrote:
> Curious. Not that I would necessarily want to do this, but from the
> JSTL specification, it almost seems like you could do something like
> this:
>
> <x:set var="username" select="$cookie:username"/>
> <c:if test="${username == 'learner'}">
>
> So it appears that simple access to cookies is in the XML tags, but
> not the core tags? Please correct me if I'm confused (likely).
Ha! Yes, you found a cute workaround that takes advantage of an
inconsistency in the current spec: cookies are easily accessed by name
using XPath but not the EL. Of course, the technical issues (and whether
we can stomach a simple name-based lookup, in view of these issues) are
the same for both the EL and the XPath variable bindings. Whichever way
the expert group decides, the EL and XPath will almost certainly be
synched with each other by the next release. (That is, they'll either
both have 'cookie' or they both won't.)
--
Shawn Bayern
Author, "JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Can you test for a cookie's value using c:if tag?
Posted by "David M. Karr" <dm...@earthlink.net>.
>>>>> "Shawn" == Shawn Bayern <ba...@essentially.net> writes:
Shawn> On Thu, 21 Mar 2002, Matt Raible wrote:
>> Is it possible to do the following with JSTL?
>>
>> <c:if test="${cookie.username == 'learner'}">
>> learner
>> </c:if>
Shawn> Ah, I was hoping someone would ask. The answer is "no, not exactly like
Shawn> that," but you can still use JSTL to access cookies.
Shawn> While web developers often have the urge to access a cookie by name, it's
Shawn> an urge that's best to resist; cookies aren't identified by name alone,
Shawn> but by name, domain, path, and security status. Thus, the best way to
Shawn> access a cookie is to loop over the list of available cookies, matching
Shawn> the one that you're interested in.
Shawn> Now, if you're just interested in name, that's fine; but JSTL doesn't go
Shawn> out of its way to support that special case. Instead, you can just write
Shawn> <c:forEach items="${pageContext.request.cookies}" var="cookie">
Shawn> <c:if test="${cookie.name == 'learner'}">
Shawn> <c:set var="cookieValue" value="${cookie.value}" />
Shawn> </c:if>
Shawn> </c:forEach>
Curious. Not that I would necessarily want to do this, but from the JSTL
specification, it almost seems like you could do something like this:
<x:set var="username" select="$cookie:username"/>
<c:if test="${username == 'learner'}">
So it appears that simple access to cookies is in the XML tags, but not the
core tags? Please correct me if I'm confused (likely).
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
dmkarr@earthlink.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to get request parameter using c taglib ?
Posted by John Baker <jb...@teamenergy.com>.
On Monday 25 Mar 2002 14H:43 pm, you wrote:
> helloo,
>
> Specs indicate <c:out value="${request:myparameter}"/>
That looks like request:myparameter not request . myparameter, note the full
stop. You want request.myparameter.
> to do an equivalent to request.getParameter("myparameter")
> but it is not good ...
>
> Have you the right syntax ?
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to get request parameter using c taglib ?
Posted by RAYMOND Romain <ro...@c-s.fr>.
ba ba ba bah :)
John Baker a écrit :
>
> On Monday 25 Mar 2002 17H:58 pm, you wrote:
> > On Mon, 25 Mar 2002, RAYMOND Romain wrote:
> > > Specs indicate <c:out value="${request:myparameter}"/> to do an
> > > equivalent to request.getParameter("myparameter") but it is not good
> > > ...
> > >
> > > Have you the right syntax ?
>
> Bah, I read getParameter as getAttribute. Bah.
>
> --
> John Baker, BSc CS.
> Java Developer, TEAM/Slb. http://www.teamenergy.com
> Views expressed in this mail are my own.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to get request parameter using c taglib ?
Posted by RAYMOND Romain <ro...@c-s.fr>.
I have dopne the same watching the doc ...
bababababahhhhhhhhhhhhhhhhhhh, sorry and thanks for the answer
${$param.myparameter} which is good
John Baker a écrit :
>
> On Monday 25 Mar 2002 17H:58 pm, you wrote:
> > On Mon, 25 Mar 2002, RAYMOND Romain wrote:
> > > Specs indicate <c:out value="${request:myparameter}"/> to do an
> > > equivalent to request.getParameter("myparameter") but it is not good
> > > ...
> > >
> > > Have you the right syntax ?
>
> Bah, I read getParameter as getAttribute. Bah.
>
> --
> John Baker, BSc CS.
> Java Developer, TEAM/Slb. http://www.teamenergy.com
> Views expressed in this mail are my own.
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to get request parameter using c taglib ?
Posted by John Baker <jb...@teamenergy.com>.
On Monday 25 Mar 2002 17H:58 pm, you wrote:
> On Mon, 25 Mar 2002, RAYMOND Romain wrote:
> > Specs indicate <c:out value="${request:myparameter}"/> to do an
> > equivalent to request.getParameter("myparameter") but it is not good
> > ...
> >
> > Have you the right syntax ?
Bah, I read getParameter as getAttribute. Bah.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: How to get request parameter using c taglib ?
Posted by Shawn Bayern <ba...@essentially.net>.
On Mon, 25 Mar 2002, RAYMOND Romain wrote:
> Specs indicate <c:out value="${request:myparameter}"/> to do an
> equivalent to request.getParameter("myparameter") but it is not good
> ...
>
> Have you the right syntax ?
The current specs don't say that. Are you reading documentation that's
out of date? (If not, let me know what gives that incorrect syntax.)
You can access a request parameter named 'myParameter' as:
${param.myParameter}
Shawn
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
How to get request parameter using c taglib ?
Posted by RAYMOND Romain <ro...@c-s.fr>.
helloo,
Specs indicate <c:out value="${request:myparameter}"/>
to do an equivalent to request.getParameter("myparameter")
but it is not good ...
Have you the right syntax ?
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
performance benchmarks of JSTL on Tomcat 4.0.3
Posted by Peter Lin <tc...@yahoo.com>.
I got side tracked for a few days, but I finally got
time to run some benchmarks with JProbe, as well as
repeat a few of my original tests to verify the
performance.
The tests were ran on the following systems.
System I - 450mhz PIII, Win2K, 512mb RAM
programs running - mcafee, aim
Server - tomcat 4.0.3
additional connector - coyote beta 3
System II - 600mhz PIII, win2k, 256mb RAM
programs running - none
Server - tomcat 4.0.3
additional connector - coyote beta 3
load testing application
Latest JMeter from jakarta
Network - LAN
JProbe 30 -
added settings for Tomcat 4.0.3
test run - 2 threads 100 iterations
The results below is the total number of Tag objects
garbage collected for the entire duration of the test.
Garbage collection was trigger right before and
immediately after the run. The GC filter was set to
"taglibs*". The system used was #2 with 600mhz cpu and
no other apps running besides JProbe and Tomcat.
JProbe GC results
---------------------------------
include directive
---------------------------------
IfTag - 11,200
WhenTag - 4,200
ExprTag - 2,800
SetTag - 1,400
OtherwiseTag - 1,200
ChooseTag - 1,200
Logger - 16,600
Total - 38,600
General memory/GC behavior - GC spiked much more
frequently than pages using action include. The
duration between GC was approximately half that of
action include.
action include
--------------------------------
IfTag - 11,00
WhenTag - 2,800
ExprTag - 2,600
Logger - 16,600
Total - 33,000
General memory/GC behavior - GC frequency was less and
the interval between GC was twice as long as pages
using include directive. It generally took 2-4x more
page hits to reach the heap max.
scriptlet page
--------------------------------
no tags were garbage collected, since none were used.
for the duration of the test, GC was trigger twice. In
comparison, include directive for the duration of the
test was called on average 30 times. action include
called GC approximately 15 times.
The results below were average from 3 runs of each
setting. The machine running JMeter was a separate
system. Only the HTML was retrieved. No images or
other files were included in the calculation of the
response times. Test performed on system #2 (600mhz,
256ram) were not heap optimized, since it is pointless
with 256mb of ram. All times are in milliseconds.
include directive - 1 thread 1000
----------------------------------
httpconnector ave - 32
cpu usage - 45-80%
coyote connector ave - 107
cpu-usage - 30-100%
include directive - 2 threads 500
----------------------------------
httpconnector ave - 403
cpu usage - 50-100%
coyote connector ave - 378
cpu usage - 40-100%
include directive - 4 threads 250
----------------------------------
httpconnector ave - 974
cpu usage - 70-100%
coyote connector - 474
cpu usage - 50-100%
include directive - 8 threads 125
----------------------------------
httpconnector ave - 2802
cpu usage - 100%
coyote connector ave - 1660
cpu usage - 60-100%
include directive - 16 threads 65
----------------------------------
httpconnector ave - could not finish
cpu usage - 100%
coyote connector ave - 2994
cpu usage - 80-100%
action include - 1 thread 1000
-----------------------------------
httpconnector ave - 48
cpu usage - 40-70%
coyote connector ave - 49
cpu usage - 40-60%
action include - 2 threads 500
-----------------------------------
httpconnector ave - 84
cpu usage - 55-95%
coyote connector ave - 86
cpu usage - 40-80%
action include - 4 threads 250
-----------------------------------
httpconnector ave - 190
cpu usage - 70-90%
coyote connector ave - 175
cpu usage - 50-90%
action include - 8 threads 125
-----------------------------------
httpconnector ave - 508
cpu usage - 70-100%
coyote connector ave - 372
cpu usage - 60-95%
action include - 16 threads 65
-----------------------------------
httpconnector ave - 1056
cpu usage - 90-100%
coyote connector ave - 808
cpu usage - 70-100%
action include - 32 threads 63
-----------------------------------
httpconnector ave - 2646
cpu usage - 100%
coyote connector ave - 1036
cpu usage - 80-100%
scriptlet page - 1 thread 1000
-----------------------------------
httpconnector ave - 22
cpu usage - 0-20%
coyote connector ave - 21
cpu usage - 0-16%
scriptlet page - 2 threads 500
-----------------------------------
httpconnector ave - 30
cpu usage - 20-40%
coyote connector ave - 28
cpu usage - 0-25%
scriptlet page - 4 threads 250
-----------------------------------
httpconnector ave - 49
cpu usage - 20-40%
coyote connector ave - 47
cpu usage - 20-35%
scriptlet page - 8 threads 125
-----------------------------------
httpconnector ave - 97
cpu usage - 20-40%
coyote connector ave - 97
cpu usage - 20-40%
scriptlet page - 16 threads 65
-----------------------------------
httpconnector ave - 179
cpu usage - 20-45%
coyote connector ave - 171
cpu usage - 20-40%
scriptlet page - 32 threads 63
-----------------------------------
httpconnector ave - 250
cpu usage - 30-60%
coyote connector ave - 257
cpu usage - 20-40%
scriptlet page - 64 threads 35
-----------------------------------
httpconnector ave - 445
cpu usage - 30-80%
coyote connector ave - 706
cpu usage - 40-90%
Tests running on system #1 were all run with the same
heap setting of "-Xms50m -Xmx280m". No additional
optimizations were used in the test.
include directive - 1 thread 1000
-----------------------------------
httpconnector ave - 24
cpu usage - 35-50%
coyote connector ave - 23
cpu usage - 30-45%
include directive - 2 threads 500
-----------------------------------
httpconnector ave - 35
cpu usage - 50-100%
coyote connector ave - 40
cpu usage - 50-90%
include directive - 4 threads 250
-----------------------------------
httpconnector ave - 241
cpu usage - 75-100%
coyote connector ave - 119
cpu usage - 65-100%
include directive - 8 threads 125
-----------------------------------
httpconnector ave - 962
cpu usage - 100%
coyote connector ave - 403
cpu usage - 65-100%
include directive - 16 threads 65
-----------------------------------
httpconnector ave - 3948
cpu usage - 100%
coyote connector ave - 1173
cpu usage - 90-100%
include directive - 32 threads 63
-----------------------------------
httpconnector ave - could not complete
cpu usage - 100%
coyote connector ave - 7907
cpu usage - 100%
action include - 1 thread 1000
-----------------------------------
httpconnector ave - 34
cpu usage - 60-80%
coyote connector ave - 35
cpu usage - 45-60%
action include - 2 threads 500
-----------------------------------
httpconnector ave - 59
cpu usage - 70-90%
coyote connector ave - 54
cpu usage - 55-80%
action include - 4 threads 250
-----------------------------------
httpconnector ave - 118
cpu usage - 75-95%
coyote connector ave - 112
cpu usage - 75-95%
action include - 8 threads 125
-----------------------------------
httpconnector ave - 221
cpu usage - 80-95%
coyote connector ave - 201
cpu usage - 75-100%
action include - 16 threads 65
-----------------------------------
httpconnector ave - 457
cpu usage - 85-100%
coyote connector ave - 423
cpu usage - 80-100%
action include - 32 threads 63
-----------------------------------
httpconnector ave - 1099
cpu usage - 100%
coyote connector ave - 860
cpu usage - 95-100%
One obvious result of these benchmarks is memory is
more crucial than CPU speed for site using lots of tag
with JSTL. Using scriptlet pages, memory is less of an
issue, but once GC kicks in, performance begins to
degrade rapidly. Sites that wish to use lot of tags
with include directive should consider having lots of
memory. Not having enough memory seriously impacts the
scalability of a website using JSP tags.
>From the JProbe garbage collection data, using tag
pooling is very desireable for deployments that use
lots of tags. Re-using tag classes will dramatically
decrease the amount of tag classes GC-ed and therefore
improve resposne time and concurrency.
peter
__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - send holiday greetings for Easter, Passover
http://greetings.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Can you test for a cookie's value using c:if tag?
Posted by Shawn Bayern <ba...@essentially.net>.
On Sat, 23 Mar 2002, Matt Raible wrote:
> Is there anyway to test if cookieValue *contains* a String, rather
> than just == 'String'?
No. For that, you'll need a custom taglib (or, of course, the dreaded
scriptlet). :)
Ultimately, I'd personally like to see some string support in JSTL (like
Bay's string taglib); hopefully, that'll come up in JSTL 1.1.
--
Shawn Bayern
Author, "JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Can you test for a cookie's value using c:if tag?
Posted by Matt Raible <ma...@raibledesigns.com>.
Is there anyway to test if cookieValue *contains* a String, rather than
just == 'String'?
> -----Original Message-----
> From: Shawn Bayern [mailto:bayern@essentially.net]
> Sent: Thursday, March 21, 2002 10:36 PM
> To: Tag Libraries Users List; matt@raibledesigns.com
> Subject: Re: Can you test for a cookie's value using c:if tag?
>
>
> On Thu, 21 Mar 2002, Matt Raible wrote:
>
> > Is it possible to do the following with JSTL?
> >
> > <c:if test="${cookie.username == 'learner'}">
> > learner
> > </c:if>
>
> Ah, I was hoping someone would ask. The answer is "no, not
> exactly like that," but you can still use JSTL to access cookies.
>
> While web developers often have the urge to access a cookie
> by name, it's an urge that's best to resist; cookies aren't
> identified by name alone, but by name, domain, path, and
> security status. Thus, the best way to access a cookie is to
> loop over the list of available cookies, matching the one
> that you're interested in.
>
> Now, if you're just interested in name, that's fine; but JSTL
> doesn't go out of its way to support that special case.
> Instead, you can just write
>
> <c:forEach items="${pageContext.request.cookies}" var="cookie">
> <c:if test="${cookie.name == 'learner'}">
> <c:set var="cookieValue" value="${cookie.value}" />
> </c:if>
> </c:forEach>
>
> I explain this in more detail in my book; interestingly
> enough, I just wrote the section describing techniques like this.
>
> --
> Shawn Bayern
> Author, "JSP Standard Tag Library" http://www.jstlbook.com
> (coming this summer from Manning Publications)
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Can you test for a cookie's value using c:if tag?
Posted by Shawn Bayern <ba...@essentially.net>.
On Thu, 21 Mar 2002, Matt Raible wrote:
> Is it possible to do the following with JSTL?
>
> <c:if test="${cookie.username == 'learner'}">
> learner
> </c:if>
Ah, I was hoping someone would ask. The answer is "no, not exactly like
that," but you can still use JSTL to access cookies.
While web developers often have the urge to access a cookie by name, it's
an urge that's best to resist; cookies aren't identified by name alone,
but by name, domain, path, and security status. Thus, the best way to
access a cookie is to loop over the list of available cookies, matching
the one that you're interested in.
Now, if you're just interested in name, that's fine; but JSTL doesn't go
out of its way to support that special case. Instead, you can just write
<c:forEach items="${pageContext.request.cookies}" var="cookie">
<c:if test="${cookie.name == 'learner'}">
<c:set var="cookieValue" value="${cookie.value}" />
</c:if>
</c:forEach>
I explain this in more detail in my book; interestingly enough, I just
wrote the section describing techniques like this.
--
Shawn Bayern
Author, "JSP Standard Tag Library" http://www.jstlbook.com
(coming this summer from Manning Publications)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>