Is it possible to get at request.getContextPath() like this:
<c:out value="${request.contextPath}"/>
Thanks!
--
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: problems with and using JSTL beta 1 version
Posted by Shawn Bayern <ba...@essentially.net>.
Helen,
> 1. SQL result display problem.
> I successfully retrieve the resultset using
>
> <c:forEach var="column" items="${row}">
> <td><c:out value="${column}"/></td>
> </c:forEach>
>
> However, the following code retrieves blank values. I can see multiple empty
> lines, which means the query is successful, but all the values are blank.
>
> <c:forEach var="row" items="${project.rows}">
> <tr>
>
> <td> <c:out value="${row.proj_name}"/> </td>
> <td> <c:out value="${row.task_name}"/> </td>
> <td> <c:out value="${row.task_status}"/> </td>
> <td> <c:out value="${row.act_name}"/> </td>
> <td> <c:out value="${row.activity_status}"/> </td>
> </tr>
> </c:forEach>
If I had to guess, I'd say that there's a mismatch between the column
capitalization that your database is returning and the ones that you're
using in your expressions (e.g., "proj_name" versus "PROJ_NAME"). JSTL is
currently case-sensitive in this regard, although we're actively
considering whether (and how) to make it case insensitive.
One easy way to tell for sure if column-name mismatches are at the root of
your problem is to use 'result.rowsByIndex' instead of 'result.rows' and
then to access column numbers instead of names.
> 2. fmt:message cannot properly display text
> I am only using fmt:message tag, all the messages are displayed as
> "???". If I type in a non-exist value as either key or message tag's
> body content, it at least displays the original value. For example
>
> <fmt:message key="engineering_name" /> (engineering_name doesn't exist in
> resource bundle)
> displays:
> ???engineering_name???
>
> This seems to me indicate that fmt tag is able to locate the bundle
> and key, but is not able to display it.
Similar to what Jan said, this sounds just like the tag isn't finding your
bundle. (As Jan said, the name for the parameter/attribute changed.)
--
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>
problems with and using JSTL beta 1 version
Posted by "Xiaotan(Helen) He" <xi...@sun.com>.
Hi,
I am trying to convert some working code from EA3 version to Beta 1 version. There
are a couple of problems that I encountered.
1. SQL result display problem.
I successfully retrieve the resultset using
<c:forEach var="column" items="${row}">
<td><c:out value="${column}"/></td>
</c:forEach>
However, the following code retrieves blank values. I can see multiple empty
lines, which means the query is successful, but all the values are blank.
<c:forEach var="row" items="${project.rows}">
<tr>
<td> <c:out value="${row.proj_name}"/> </td>
<td> <c:out value="${row.task_name}"/> </td>
<td> <c:out value="${row.task_status}"/> </td>
<td> <c:out value="${row.act_name}"/> </td>
<td> <c:out value="${row.activity_status}"/> </td>
</tr>
</c:forEach>
2. fmt:message cannot properly display text
I am only using fmt:message tag, all the messages are displayed as "???". If I
type in a non-exist value as either key or message tag's body content, it at least
displays the original value. For example
<fmt:message key="engineering_name" /> (engineering_name doesn't exist in
resource bundle)
displays:
???engineering_name???
This seems to me indicate that fmt tag is able to locate the bundle and key, but
is not able to display it.
Any idea?
Thanks,
-- Helen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSTL EL parser pool?
Posted by peter lin <pe...@labs.gte.com>.
Here are some thoughts....
Shawn Bayern wrote:
>
> On Fri, 22 Mar 2002, peter lin wrote:
>
>
> Interesting thought, Peter.
>
> Given that instantiating an Evaluator object involves no specific logic on
> construction, the only cost of not having a pool is that of object
> creation itself, which should be exceptionally well optimized under any
> JIT. As a general rule, I strongly hesitate to pool objects unless
> there's a demonstrated reason it'll help. (Most products pool objects WAY
> too much, which leads to unnecessary complexity and -- indeed -- potential
> performance problems.) The performance you're experiencing doesn't sound
> too good, but do you have any reason to think that the logic within
> ExpressionEvaluatorManager (in particular) is to blame?
actually I don't think ExpressionEvaluationManger by itself is the
blame. I think it's the combination of a lot of little things that add
up to a problem. I have no conclusive proof, but right now my guess is
my test pages are using lots of local variables. Since the test system
only has 256ram on win2K, at 4 concurrent requests it might be reaching
the limit for local variables causing GC to start. The reason I suspect
this is the dramatic CPU usage. The performance degrades as CPU usage
increases from what I see. For minimal load, I seriously doubt there
will be any benefit. In fact there's probably going to be decreased
performance for 1-2 concurrent connections.
>
> The evaluator keeps a static cache of values, so literally the only
> benefit of pooling our interpreter instances would be to save the
> instantiation itself, which should take about ten low-level instructions
> on a modern JIT. (That is, the evaluator has an empty constructor, and
> all its work is done on the stack -- with the aid of a few static caches.)
>
> Thanks very much for the suggestion, though; I'd be curious if you have
> any data that does implicate one part of the JSTL RI over another.
>
I doubt instantiation is the cause. The first candidate for improvemnet
with the test pages I've written is recycling tag objects. For example
the test page is broken up into 20-24 pages. When I count the number of
times a new Tag is created I get:
when - 22
otherwise - 7
if - 55
expr - 23
choose - 7
--------------
Total 114
Since the evalutor caches the values, I was thinking after all the other
steps were done, it might be a candidate for pooling, though not by
default. It wouldn't make sense to have the default expression manager
to be pooled. Very few installation need to support 8-13million hits a
day. In my mind, extreme performance requirements might benefit in
stability and reduced GC from pooling the parsers. Another interesting
fact is the source generated by jasper is 4320 lines long when using
JSTL with include directive <%@ include ..%> :).
If you look at the numbers I posted on tomcat-user, you'll see that
using JSTL with action include performs better than JSTL with include
directive. Once I get numbers with JProbe, I will post them for further
discussion :)
again thanks for taking time to read and respond.
peter lin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: JSTL EL parser pool?
Posted by Shawn Bayern <ba...@essentially.net>.
On Fri, 22 Mar 2002, Shawn Bayern wrote:
> The evaluator keeps a static cache of values, so literally the only
> benefit of pooling our interpreter instances would be to save the
> instantiation itself, which should take about ten low-level instructions
> on a modern JIT. (That is, the evaluator has an empty constructor, and
> all its work is done on the stack -- with the aid of a few static caches.)
By the way, this implies that a SINGLE instance, instead of a pool, would
work just as well too. (The existing EEM code is from a time when this
wasn't the case.) Once we're sure of the final EL interface, I'll plan on
using just one instance. But again, the actual performance difference on
an effective JIT should be negligible.
--
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: JSTL EL parser pool?
Posted by Shawn Bayern <ba...@essentially.net>.
On Fri, 22 Mar 2002, peter lin wrote:
> I've been doing benchmarks with JSTL on some dynamic pages and noticed
> under medium & heavy load 4-64 concurrent connections, the performance
> degrades rapidly. I looked at ExpressionEvaluatorManager and it looks
> like it doesn't create a pool of parsers. I posted some benchmarks on
> tomcat user mailing list
> http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg48946.html
>
> It might be beneficial to recyle the parsers. this way it would reduce
> memory usage and gc. The reason I say is because I am witnessing heavy
> disk caching with 4+ concurrent connections. These problems might be
> solved by adding 1gig of memory, but that would only be a temporary
> fix, especially for systems that can only support 2gigs of ram.
Interesting thought, Peter.
Given that instantiating an Evaluator object involves no specific logic on
construction, the only cost of not having a pool is that of object
creation itself, which should be exceptionally well optimized under any
JIT. As a general rule, I strongly hesitate to pool objects unless
there's a demonstrated reason it'll help. (Most products pool objects WAY
too much, which leads to unnecessary complexity and -- indeed -- potential
performance problems.) The performance you're experiencing doesn't sound
too good, but do you have any reason to think that the logic within
ExpressionEvaluatorManager (in particular) is to blame?
The evaluator keeps a static cache of values, so literally the only
benefit of pooling our interpreter instances would be to save the
instantiation itself, which should take about ten low-level instructions
on a modern JIT. (That is, the evaluator has an empty constructor, and
all its work is done on the stack -- with the aid of a few static caches.)
Thanks very much for the suggestion, though; I'd be curious if you have
any data that does implicate one part of the JSTL RI over another.
--
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>
JSTL EL parser pool?
Posted by peter lin <pe...@labs.gte.com>.
I've been doing benchmarks with JSTL on some dynamic pages and noticed
under medium & heavy load 4-64 concurrent connections, the performance
degrades rapidly. I looked at ExpressionEvaluatorManager and it looks
like it doesn't create a pool of parsers. I posted some benchmarks on
tomcat user mailing list
http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg48946.html
It might be beneficial to recyle the parsers. this way it would reduce
memory usage and gc. The reason I say is because I am witnessing heavy
disk caching with 4+ concurrent connections. These problems might be
solved by adding 1gig of memory, but that would only be a temporary fix,
especially for systems that can only support 2gigs of ram.
peter lin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re:
Posted by Shawn Bayern <ba...@essentially.net>.
On Fri, 22 Mar 2002, John Baker wrote:
> Is it possible to get at request.getContextPath() like this:
>
> <c:out value="${request.contextPath}"/>
'contextPath' in that expression is a scoped attribute. If you want to
access properties of the HttpServletRequest object itself, you need to do
so through 'pageContext'. That is:
${pageContext.request.contextPath}
--
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>