In both JSTL 1.1 and 1.0 specifications nothing is mentioned about nested x:forEach loops where the inner x:forEach iterates over the parsed results of a *different* xml file. But between JSTL 1.0 and JSTL 1.1, this very behavior change. For example : ------------------------------------------------------------------------------------------------------ collections.xml <?xml version="1.0" encoding="ISO-8859-1"?> <collections> <collection> <id>horror</id> <name>Horror novel</name> </collection> <collection> <id>scifi</id> <name>Sci-Fi novel</name> </collection> </collections> ------------------------------------------------------------------------------------------------------ books.xml <?xml version="1.0" encoding="ISO-8859-1"?> <books> <book> <collection_id>scifi</collection_id> <title>Robots</title> </book> <book> <collection_id>scifi</collection_id> <title>The Moon is a Hashes Mistress</title> </book> <book> <collection_id>scifi</collection_id> <title>Spaceship Tropper</title> </book> <book> <collection_id>horror</collection_id> <title>This</title> </book> </books> ------------------------------------------------------------------------------------------------------ books.jsp <%@ taglib prefix="c" uri="/WEB-INF/c.tld" %> <%@ taglib prefix="x" uri="/WEB-INF/x.tld" %> <c:import var="xml_collections" url="http://localhost/collections.xml" /> <x:parse xml="${xml_collections}" var="collections" scope="request"/> <c:import var="xml_books" url="http://www.localhost/books.xml" /> <x:parse xml="${xml_books}" var="books" scope="request"/> <x:forEach select="$collections/collections/collection" var="collection"> <x:out select="$collection/name" /> <ul> <x:forEach select="$books/books/book[collection_id=$collection/id]" var="book"> <li><x:out select="$book/title" /></li> </x:forEach> </ul> </x:forEach> ------------------------------------------------------------------------------------------------------ Output (WebSphere 5 using JSTL 1.0) Horror novel <ul> <li>This</li> </ul> Sci-Fi novel <ul> <li>Robots</li> <li>The Moon is a Hashes Mistress</li> <li>Spaceship Tropper</li> </ul> ------------------------------------------------------------------------------------------------------ Output (WebSphere 6 using JSTL 1.1) Horror novel <ul> </ul> Sci-Fi novel <ul> </ul>
This looks a lot like #30068, which is now resolved with a fix committed to SVN trunk. Assuming you don't feel like building from trunk, I'll upload a build tomorrow so you can see if that fixes this too.
(In reply to comment #1) > This looks a lot like #30068, which is now resolved with a fix committed to SVN > trunk. Assuming you don't feel like building from trunk, I'll upload a build > tomorrow so you can see if that fixes this too. I never use SVN and I'm not sure I got access to it. So, I try to unzip the standard.jar file. I then use cavaj to modify the XPathUtil.class and then zip back the file, restart the application (not the server) and it still buggy. Can I use the latest nightly binary development distribution or can you send me a fixed standard.jar? Thank you very much! *** This bug has been marked as a duplicate of 30068 ***
I try to install the latest nightly build (January 29th 2007), and it's still buggy.
Assuming you got the nightly build from http://people.apache.org/builds/jakarta-taglibs/nightly/projects/, it looks like that's been broken since 29-Aug-2006.
(In reply to comment #4) > Assuming you got the nightly build from > http://people.apache.org/builds/jakarta-taglibs/nightly/projects/, it looks like > that's been broken since 29-Aug-2006. Where can I find a fixed version of standard.jar?
Give the following pair of jars a shot: http://people.apache.org/~bayard/standard-1.1/ This looks so like 30068 and that one seems to be fixed now (it's got a unit test so it must be fixed right? :) ).
(In reply to comment #6) > Give the following pair of jars a shot: > > http://people.apache.org/~bayard/standard-1.1/ > > This looks so like 30068 and that one seems to be fixed now (it's got a unit > test so it must be fixed right? :) ). I did manage to compile the taglibs source. But I got the same behavior. I also try your snapshot and it was not working either. I try a test with a fresh install of the latest Tomcat using your snapshot file, and I got: javax.servlet.ServletException: org/apache/xpath/XPathException Do you want me to 'Reassign bug to owner of selected component '?
In WebSphere 6, I add a <c:catch> before the <x:forEach> and I got: javax.servlet.jsp.JspTagException: Illegal argument evaluating XPath expression "/collections/collection": java.lang.IllegalArgumentException: Node must be non-null for getDTMHandleFromNode
When I run your example under Tomcat 5.5/JDK 1.5 and the latest source I get: Horror novel <ul> <li>This</li> </ul> Sci-Fi novel <ul> <li>Robots</li> <li>The Moon is a Hashes Mistress</li> <li>Spaceship Tropper</li> </ul> I had to change the namespace declarations to: <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %> <%@ taglib prefix="x" uri="http://java.sun.com/jsp/jstl/xml" %> as that's how I have things setup. So looks like it's environment based. Which JVM version are you on? Is Websphere 6 still 1.3 based? Or is that a 1.4 based one? The getDTMHandlerFromNode method is in the XPathContext class from Xalan. I'm using Xalan 2.7.0 for my testing. Any idea what version you or Websphere are using?
Local Tomcat: 5.5.20 Java: 1.5.0_08 Xalan: ? Server WebSphere: 6.0.2.7 Java: 1.4.2 Xalan: 2.6.9 Both return the error.
I put the c.tld and x.tld in WEB-INF/ and put the tag directives back to how they are in your example and it still works. I think we should ignore Websphere for the moment and just consider your local environment which appears much the same as mine (Tomcat 5.5.20, JDK 1.5.0_09 & Linux 2.6.9 kernel). All I have thought wise is to try to nail down the versions of Xalan in use so we can try to replicate on the same versions. The Taglibs code goes against the Xalan package, and I'm pretty sure the JVM doesn't offer that package in 1.5.x (they change the package names afaik). As far as I can tell, there hasn't been a 2.6.9 of Xalan, just a 2.6.0 and then a 2.7.0. Might be that the .9 is IBM specific though. Once we get passed that, it would seem that we have exactly the same setup and one is working and one is not. Ugh :)
First thing tomorrow I will run: java org.apache.xalan.xslt.EnvironmentCheck to get the version of Xalan use by both environment. Once again thank you, you have no idea how this is helping me.
Ok, I think I found my problem, at least on the local side version (Tomcat 5). I forget to copy the: xalan.jar, xercesImpl.jar, xml-apis.jar and xsltc.jar files into the /WEB-INF/lib directory. Now, if a do a test with the Xalan 2.7.0 AND your snapshot version of the jstl.jar and standard.jar file, I got the right answer. :-) I will test first thing tomorrow the solution on my developer server (WebSphere 6). - I will upgrade to Xalan 2.7.0 (copying all files needed in /WEB-INF/lib this time :-) - I will use your snapshot version of jstl.jar and standard.jar - and... hope for the best. I will give you feedback as soon as possible.
The solution didn't work on WebSphere 6. I check for rogue copy xalan.jar file on the system, but I din't find any in the JAVA_HOME use by WebSphere. WebSphere use Java 1.4.2 and not 1.5.x. Can this be the reason why it is not working? I will try to install the JDK 1.4 Compatability Package (on my local Tomcat) to see if this can be the problem.
Haven't followed this closely yet, but make sure you *really* know where your app server is loading JAXP/Xerces/Xalan stuff from: jaxp.jsp: --------- <%@ page contentType="text/plain; charset=UTF-8" %> <%@ page import="java.net.*, javax.xml.parsers.*, javax.xml.transform.*" %> <%! public URL getClassAsResource(Class clazz) { String className = clazz.getName(); String classNameAsPath = className.replace('.', '/'); String classResourceName = "/" + classNameAsPath + ".class"; return clazz.getResource(classResourceName); } %> <% SAXParserFactory parsers = SAXParserFactory.newInstance(); SAXParser parser = parsers.newSAXParser(); TransformerFactory transformers = TransformerFactory.newInstance(); Transformer transformer = transformers.newTransformer(); %> SAXParser location: <%= getClassAsResource(parser.getClass()) %> Transformer location: <%= getClassAsResource(transformer.getClass()) %>
You can also use this (or combine with previous example) to get the versions (and some other useful info) for Xerces & Xalan: apachexml.jsp: -------------- <%@ page contentType="text/plain; charset=UTF-8" %> Xerces version: <%= org.apache.xerces.impl.Version.getVersion() %> Xalan version: <%= org.apache.xalan.Version.getVersion() %> Xalan env check: <%= new org.apache.xalan.xslt.EnvironmentCheck().checkEnvironment(new java.io.PrintWriter(out)) %>
(In reply to comment #16) > You can also use this (or combine with previous example) to get the versions > (and some other useful info) for Xerces & Xalan: > > apachexml.jsp: > -------------- > > <%@ page contentType="text/plain; charset=UTF-8" %> > > Xerces version: <%= org.apache.xerces.impl.Version.getVersion() %> > > Xalan version: <%= org.apache.xalan.Version.getVersion() %> > > Xalan env check: > <%= new org.apache.xalan.xslt.EnvironmentCheck().checkEnvironment(new > java.io.PrintWriter(out)) %> > Running your first example, I got: SAXParser location: null Transformer location: null In the second one, I got: Xerces version: XML4J 4.3.7 Xalan version: XSLT4J Java 2.6.9 Xalan env check: #---- BEGIN writeEnvironmentReport(Revision: 1.31.1.3): Useful stuff found: ---- java.version=1.4.2 version.xalan2x=XSLT4J Java 2.6.9 version.JAXP=1.1 or higher version.SAX=2.0 version.crimson=not-present java.class.path=WARNING: SecurityException thrown accessing system classpath properties version.ant=not-present version.b2bxml=1.2.1 sun.boot.class.path= /usr/local/was/v6/java/jre/lib/ext/ibmorb.jar: /usr/local/was/v6/java/jre/lib/ext/ibmext.jar: /usr/local/was/v6/java/jre/lib/core.jar: /usr/local/was/v6/java/jre/lib/graphics.jar: /usr/local/was/v6/java/jre/lib/security.jar: /usr/local/was/v6/java/jre/lib/server.jar: /usr/local/was/v6/java/jre/lib/xml.jar: /usr/local/was/v6/java/jre/lib/charsets.jar: /usr/local/was/v6/java/jre/classes: /usr/local/was/v6/java/jre/lib/ibmcertpathprovider.jar: /usr/local/was/v6/java/jre/lib/ibmjaaslm.jar: /usr/local/was/v6/java/jre/lib/ibmjcefw.jar: /usr/local/was/v6/java/jre/lib/ibmjgssprovider.jar: /usr/local/was/v6/java/jre/lib/ibmjssefips.jar: /usr/local/was/v6/java/jre/lib/ibmjsseprovider.jar: /usr/local/was/v6/java/jre/lib/ibmorb.jar: /usr/local/was/v6/java/jre/lib/ibmorbapi.jar: /usr/local/was/v6/java/jre/lib/ibmpkcs.jar version.DOM.draftlevel=2.0fd version.DOM=2.0 version.xalan1=not-present version.xalan2_2=XSLT4J Java 2.6.9 version.xerces2=XML4J 4.3.7 version.xerces1=not-present #----- END writeEnvironmentReport: Useful properties found: ----- # YAHOO! Your environment seems to be OK. true It seem, WebSphere 6 use Xalan 2.6.9 (a version not suppose to exist when I check on Xalan website). How can I fix this? Do you know if WebSphere supported the Endorsed Standards Override Mechanism?
Xalan gets embedded in the JVM. Prior to some point it got embedded with the existing apache package names - so it's possible that 2.6.9 is a Sun Xalan number and it's coming from the JVM. I'll try running the version number test against a 1.4.2 JVM in a couple of hours unless someone else gets it done (work intervenes til then).
Sun's 1.4.2_13 JDK on Linux has a Xalan 2.4.1. Apple's 1.4 JDK has 2.4.1 too (probably copied from Sun). So chances are, the xslt4j and xml4j are coming from the IBM JDK version. I'm guessing that XSLT4J and XML4J are the internal IBM names for forks of Xalan and Xerces - they're much involved in said libraries.
I try to install Tomcat using the JDK 1.4 compatibility package and then try to use JDK 1.4 to test is this is a problem with JDK version instead of Xalan incompatibility. The JSP wouldn't compile. One on your dig the doc from WebSphere and confirm that IBM JVM is working with Xalan 2.6.9. But what is troubling me is that IBM mention that this is the only version of Xalan support by the IBM JVM. We gonna open a ticket with IBM about that. I will keep you inform.
(In reply to comment #20) > I try to install Tomcat using the JDK 1.4 compatibility package and then try to > use JDK 1.4 to test is this is a problem with JDK version instead of Xalan > incompatibility. > > The JSP wouldn't compile. > > One on your dig the doc from WebSphere and confirm that IBM JVM is working with > Xalan 2.6.9. But what is troubling me is that IBM mention that this is the only > version of Xalan support by the IBM JVM. We gonna open a ticket with IBM about > that. I will keep you inform. Is there any update to this issue? Any response from IBM?
Inactive issue. Resolving as Worksforme as the issue was in the reporter's environment.