tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Johnson, Chris" <chrisjohn...@ti.com>
Subject RE: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Date Tue, 16 Mar 2004 17:28:41 GMT
Thanks for all of the help so far.

I submitted bug 27717.

Chris

-----Original Message-----
From: Pierre.Delisle@Sun.COM [mailto:Pierre.Delisle@Sun.COM] 
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" <chrisjohnson@ti.com>:
> 
> 
>>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:kris@dotech.com]
>>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" <chrisjohnson@ti.com>:
>>
>>
>>>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:kris@dotech.com]
>>>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" <chrisjohnson@ti.com>:
>>>
>>>
>>>>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:kris@dotech.com>
>>>D.O.Tech       <http://www.dotech.com/>
>>
>>--
>>Kris Schneider <mailto:kris@dotech.com>
>>D.O.Tech       <http://www.dotech.com/>
> 
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: taglibs-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: taglibs-user-help@jakarta.apache.org


Mime
View raw message