tomcat-taglibs-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justyna Horwat <Justyna.Hor...@Sun.COM>
Subject Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Date Wed, 28 Jul 2004 17:35:45 GMT
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.DocumentBuilderFactoryImpl"


Lookup procedure (for my own reference):
http://java.sun.com/j2se/1.4.2/docs/api/javax/xml/parsers/DocumentBuilderFactory.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#newInstance(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:chrisjohnson@ti.com]
> 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: 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
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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