Justyna, I added both the options, but the result is the same. It takes 6 seconds to finish an x:foreach loop over 250 records. When using x:transform it gives an immediat result. With 1.0 there is no problem either. I kan reproduce this behaviour any time.
Thanks Wim -----Oorspronkelijk bericht----- Van: Justyna Horwat [mailto:[EMAIL PROTECTED] Verzonden: woensdag 28 juli 2004 19:36 Aan: Tag Libraries Users List Onderwerp: Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) Hi Wim, Have you tried the following to avoid the property file lookups? What were the results when you set the following properties? ---- jaxp.properties file lookup: JAVA_OPTS="$JAVA_OPTS -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBu ilderFactoryImpl" Lookup procedure (for my own reference): http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/DocumentBuilderFac tory.html#newInstance() ---- xalan.properties file lookup: JAVA_OPTS="$JAVA_OPTS -Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault" Lookup procedure (for my own reference): http://xml.apache.org/xalan-j/apidocs/org/apache/xml/dtm/DTMManager.html#new Instance(org.apache.xml.utils.XMLStringFactory) ---- Thanks, Justyna Wim Goossens wrote: > 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] > --------------------------------------------------------------------- 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]
