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/> -- 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]
