jakarta-taglibs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kris Schneider <k...@dotech.com>
Subject Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03)
Date Mon, 14 Feb 2005 00:44:08 GMT
Instead of patching back to Jaxen/SAXPath, it might have been better to 
investigate Xalan's CachedXPathAPI as outlined in my comment for this bug:

http://issues.apache.org/bugzilla/show_bug.cgi?id=27717

The things I'm unsure of are whether or not it's safe to cache the 
information at the risk of missing changes to the underlying document and 
how we should manually manage the cache. Most of that uncertainty is just 
not being all that familiar with those corners of the code...

Wim Goossens wrote:
> "Wim Goossens" schreef:
> 
>> 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
>>
>>
> Chris,
> 
> The problem with the <x:foreach> tag still exists. It is there for one 
> year now.
> I have made a workaround, I made a new standard.jar and jstl.jar.
> It is dependent again from Jaxen/SAXPath instead of Xalan.
> 
> Using xslt was not an option. We use other tags to often to do extra
> manipulations on the data. (like <fmt:message> for i18n, and our own tags
> for populating drop downs  and tags for applying security restrictions 
> on columns)
> 
> Anyway, compared to the previous version, <x:foreach> is blazing fast
> again. (about 30 times faster)
> 
> I can wait now for a bug fix. It is not urgent anymore.
> (Probably it will come soon.)
> 
> If you like, i can send you the jar's.
> 
> Regards
> Wim Goossens

-- 
Kris Schneider <mailto:kris@dotech.com>
D.O.Tech       <http://www.dotech.com/>

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


Mime
View raw message