Re: escapeXml() optimizations
Try it simpler: Yes, that's much nicer. See what happens when I tried to fit a solution in to the previous coding paradigm? wink This was better refactored and it certainly does the job much nicer. The only change I'd make is to make the StringBuffer size length+5 to ensure we can at least handle the largest substitution for the first escaping. That way, if there's only one escape to be done, you are positive the buffer is big enough, and you only have to fret about the buffer reallocations within StringBuffer if there are multiple such instances. I'm sure other techniques could be done, but they are probably overkill, like once one substition is found to be needed, the software could determine how many such substitutions are in the remaining input string to determine how much fudge to add to handle all escaping using something like length + (numberOfEscapableCharacters * 5). As to faster, much depends on your data input. For example, if your output strings tend to be 16 or fewer characters (unlikely in my book), then there's no improvement on the buffer side and a little extra processing would add some time. But for just about every other case, the benefits can be huge since a single buffer reallocation requires a new object to be created and the old buffer to be copied into the new buffer. Nice touch and I hope this gets added to the taglibs code so that we can all benefit.. David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
fn:escapeXml() optimizations
In looking over the standard fn:escapeXml code, it seems that there may be
two simple optimizations that would benefit the method
org.apache.taglibs.standard.tag.common.core.Util.escapeXml()
The original code is:
public static String escapeXml(String input) {
StringBuffer sb = new StringBuffer();
for (int i = 0; i input.length(); i++) {
char c = input.charAt(i);
if (c == '')
sb.append(amp;);
else if (c == '')
sb.append(lt;);
else if (c == '')
sb.append(gt;);
else if (c == '')
sb.append(#034;);
else if (c == '\'')
sb.append(#039;);
else
sb.append(c);
}
return sb.toString();
}
The simplest optimization would be to create the 'sb' buffer at least as big
as the 'input' string. After all, even if there were no actual
substitutions, the 'sb' would be as big, and this would avoid StringBuffer
doing a lot of reallocations, especially if 'input' is more than the 16
characters, the default capacity of a StringBuffer. This could be
accomplished with just something like:
StringBuffer sb = new StringBuffer(input.length());
You could try to be a bit creative and assume it might be at least a bit
bigger and use:
StringBuffer sb = new StringBuffer(input.length() + 32);
A more sophisticated optimization would require two loops. The first would
look very much like the existing loop, but no 'sb' StringBuffer would be
created until one of the special characters was found. The gamble is that
the string contains no characters to be escaped, no extra objects would be
created. It would look something like:
public static String escapeXml(String input) {
StringBuffer sb = null;
int length = input.length();
int currentPos;
for (int currentPos = 0; currentPos length; currentPos++) {
char c = input.charAt(currentPos);
if (c == '') {
sb = new StringBuffer(length+4);
sb.append(input.substring(0,currentPos)); // copy over the
string up until we found this char
sb.append(amp;);
break;
}
else if (c == '') {
sb = new StringBuffer(length+3);
sb.append(input.substring(0,currentPos)); // copy over the
string up until we found this char
sb.append(lt;);
break;
}
else if (c == '') {
sb = new StringBuffer(length+3);
sb.append(input.substring(0,currentPos)); // copy over the
string up until we found this char
sb.append(gt;);
break;
}
else if (c == '') {
sb = new StringBuffer(length+5);
sb.append(input.substring(0,currentPos)); // copy over the
string up until we found this char
sb.append(#034;);
break;
}
else if (c == '\'') {
sb = new StringBuffer(length+5);
sb.append(input.substring(0,currentPos)); // copy over the
string up until we found this char
sb.append(#039;);
break;
}
}
// If we didn't create a new buffer, then the input string didn't
need any escaping so we win big time
// and we can just return the same string they gave us (no object
creation, no copying).
if ( sb == null )
return input;
// Oh well, we did have some escaping to do, so let's check the rest
to see if there are any more to do.
for ( ++currentPos; currentPos length; ++currentPos) {
char c = input.charAt(currentPos);
if (c == '')
sb.append(amp;);
else if (c == '')
sb.append(lt;);
else if (c == '')
sb.append(gt;);
else if (c == '')
sb.append(#034;);
else if (c == '\'')
sb.append(#039;);
else
sb.append(c);
}
return sb.toString();
}
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
EL not being evaluated?
I've installed JDK 1.4.2_03, Tomcat 5.0.18 and Apache's JSTL 1.1 on RH Linux
9.
My XHTML JSP contains a simple construct: p1 + 2 + 3 = c:out
value=${1+2+3}//p
But the expression is not being evaluated, yet the c:out tag is being
processed fine. The output just looks like:
1 + 2 + 3 = ${1+2+3}
Is there a trick to getting the expressions configured to work with Tomcat
5?
Thanks,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EL not being evaluated?
Since you're using a JSP 2.0 container, you should be able to just do:
p1 + 2 + 3 = ${1+2+3}/p
Make sure you're using a Servlet 2.4 deployment descriptor.
That didn't work for me. Perhaps it's your last comment. What does it mean
to have a 2.4 deployment descriptor for the JSP page? Maybe that's where
I've gone wrong... It seems like it has to be just a configuration issue.
I have the jstl.jar and standard.jar in the WEB-INF/lib directory, and I've
put the c.tld in WEB-INF and updated web.xml to point to it using:
taglib
taglib-urihttp://java.sun.com/jsp/jstl/core/taglib-uri
taglib-location/WEB-INF/c.tld/taglib-location
/taglib
Thanks,
David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: EL not being evaluated?
I think you need to indicate in the web.xml that this is a jsp version 2 web application, otherwise the container assumes the web application is written for an old jsp version where not the container but the taglib does the EL evaluation (you would need the 1.0.5 taglib version for this). That's no doubt my problem. What's sort of entries are needed for web.xml to show it's JSP version 2? Is this the WEB-INF/web.xml file or tomcat's conf/web.xml that needs to be changed? Thanks, David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EL not being evaluated?
Thanks. The comments below did it for me. However, I still had some JAR file location issues (tomcat's common/endorsed for the webapps WEB-INF/lib). Do most people put the XERCES, XALAN, JSTL/STANDARD jars in the endorsed location or do they just keep it with their webapps? Right now, I seem to be working with XERCES and XALAN in endorsed, and the JSTL/STANDARD in my WEB-INF/lib. Obviously, I'd prefer to have everything in the WEB-INF/lib since it would be packaged nicely together, or I'd prefer all these non-app JARs to be in the endorsed area. Even though everything appeared okay with my initial EL, I did note the following exception in catalina.log: java.lang.NullPointerException at org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:557) at org.apache.jasper.compiler.Compiler.isOutDated(Compiler.java:487) at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:5 50) at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:2 91) at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:301) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:248) at javax.servlet.http.HttpServlet.service(HttpServlet.java:856) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application FilterChain.java:284) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh ain.java:204) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja va:257) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContext Valve.java:245) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja va:199) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:151) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase .java:587) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:195 ) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:151) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:164 ) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:149) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:578) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:149) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java :156) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex t.java:151) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:564) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:972) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:206) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne ction(Http11Protocol.java:700) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:584) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav a:683) at java.lang.Thread.run(Thread.java:534) David Instead of: !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app ... /web-app Use: web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 ... /web-app Get rid of the taglib element and the TLD file, as of JSP 1.2 you don't need them for packaged taglibs. Just use the proper URI in the taglib directive in your JSP: %@ taglib prefix=c uri=http://java.sun.com/jsp/jstl/core; % - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
