Chris, Kris, Pierre, Do you know anything about a fix for this problem ? I also submitted a bug report, probably at the wrong place, in february. No solution so far. http://developer.java.sun.com/developer/bugParade/bugs/4993200.html
Regards, Wim -----Oorspronkelijk bericht----- Van: Johnson, Chris [mailto:[EMAIL PROTECTED] Verzonden: dinsdag 16 maart 2004 18:29 Aan: Tag Libraries Users List Onderwerp: RE: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) Thanks for all of the help so far. I submitted bug 27717. Chris -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 10:58 AM To: Tag Libraries Users List Subject: Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) 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.DTMManagerDefau >>lt >>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.xerc e >>>s. >>>jaxp.DocumentBuilderFactoryImpl >>> >> >>-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserF >>ac >> >>>toryImpl >>> >> >>-Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.Tr >>an >> >>>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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
