Yes, as Kris mentioned, please file a bug report with proper test cases. We'll have a look into it.
-- Pierre
Kris Schneider wrote:
You're posting to the right place to make people aware of the problem. To formalize the issue, a bug report should probably get submitted:
http://issues.apache.org/bugzilla/enter_bug.cgi?product=Taglibs
As part of the report, it would be helpful to include a simplified test case (XML and JSP files) that reproduces the problem. If you have any questions about the bug submission process just let me (us) know. At this point, the problem seems to be either the way JSTL is using Xalan or Xalan itself.
Quoting "Johnson, Chris" <[EMAIL PROTECTED]>:
That gets rid of the xalan file search, but the performance is still awful. For now I guess I'll try to look into xslt, but this looks like a bug that needs to be fixed or something. Who else needs to know about this to get it either fixed, or to tell me what else I might be doing wrong (if anything). Here's more of what truss is spitting out if that helps:
lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0) = 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x00000000) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778) = 0 lwp_mutex_lock(0x0002E778) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 lwp_mutex_unlock(0x0002E848) = 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 lwp_mutex_unlock(0x0002E848) = 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0) = 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x00000000) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778) = 0 lwp_mutex_lock(0x0002E778) = 0 lwp_mutex_lock(0x0002E848) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0
It looks like a lot of locking, unlocking and waiting to me, but what do I know?
Any help you can get me in escalating this would be much appreciated.
Thanks again, Chris
-----Original Message-----
From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 3:37 PM
To: Tag Libraries Users List
Subject: RE: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Try adding -Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault to JAVA_OPTS.
Quoting "Johnson, Chris" <[EMAIL PROTECTED]>:
Thanks, Kris.
I did all that you suggested (setting the system properties and installing new jars), and indeed tomcat doesn't seem to be searching for the jaxp.properties file any longer. But, the performance is still just about as bad as before. So, I did truss again and now tomcat is looking for xalan.properties (stat64("/usr/j2sdk1.4.2_03/jre/lib/xalan.properties", 0xDF47F850) Err#2 ENOENT), just about as much, if not more, than it was for jaxp.properties. So how can I fix this?
Chris
-----Original Message----- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 2:32 PM To: Tag Libraries Users List Subject: Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Interesting. <x:forEach> has been tagged as a performance problem before for JSTL 1.1, but without the accompanying truss info. The XPath engine for JSTL was changed from Jaxen/SAXPath in 1.0 to Xalan in 1.1. If you can replace <x:forEach> with <x:transform> and an XSLT stylesheet, that seemed to help with the last performance issue. Otherwise, you could try explicitly configuring JAXP by setting the appropriate system properties (assuming Xerces and Xalan):
env JAVA_OPTS="-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerce
s.
jaxp.DocumentBuilderFactoryImpl
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFac
toryImpl
-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.Tran
sformerFactoryImpl" $CATALINA_HOME/bin/startup.sh
That way, jaxp.properties should never be searched for. You may also want to download the latest Xalan release and dump the following in
$CATALINA_HOME/common/endorsed:
xalan.jar xercesImpl.jar xml-apis.jar
Quoting "Johnson, Chris" <[EMAIL PROTECTED]>:
Hello,
I'm new to the world of JSP/JSTL, but have managed to get some code running under tomcat 4.1.29 (bundled with jboss 3.2.3 - as I'm using
JMS too)/JSTL 1.0. I'm using java 1.4.2_03.
I'm using only the c and x libraries currently, but wanted to use the
new EL functions of JSTL 1.1, so I installed tomcat 5.0.19 alongside
the previously mentioned jboss/tomcat versions.
I've gotten the code to run under the new tomcat, but the performance
is terrible. I've narrowed the performance problem down to any <x:forEach> loop. There wasn't anything of interest in the tomcat log, so I did a truss on the tomcat process, and found it spitting
out
this error over and over: stat64("/usr/j2sdk1.4.2_03/jre/lib/jaxp.properties", 0xDF97FFF8) Err#2 ENOENT. I understand this to be tomcat looking
for
the jaxp.properties file and not finding it. I never saw this error message while trussing the tomcat 4.1.29 process, and it processes
the
xml extremely quickly.
With the older tomcat and JSTL 1.0, I didn't have to do any special
configuration of jaxp (I understood that to be built into java 1.4.2x), so I figured it would be the same with the newer tomcat,
but
I guess not.
So far I've tried setting parser system properties in the web.xml and
in files under META-INF with no change. What am I missing? If someone can just point me to some good docs on the subject, I'd appreciate it greatly.
Thanks, Chris Johnson
-- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/>
-- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
