(This message is based on my update to the Pluto list.) What follows is a bit rambling. In summary: I've managed to get the test portlets to render in the unit test framework by copying the tld files to the /testsuite area, and modifying the testsuit web.xml. I feel there's a better way, but for now I think it does what I need. I'll continue to build unit tests to check the rendered content returned, then to run and check (some of) the actual tests.
> It looks like you're not picking up the tld. We have a similar bug > logged in which this happens with JBoss. My guess is that it's a result > of the fact that the jar containing the tlds is either not referenced > within web.xmol (which it doesn't have to be) or within a jar in > WEB-INF/lib. Instead, it's in the taglib jar which is included in > common along with the container libraries. > > However, now that I've seperated the classes into their own jar - they > don't have to be deployed that way. . .perhaps we can think through the > reprecussions of adding that jar to web-inf/lib . . . > > Play around with different possibilities and let me know what you find. > I think this is probably something that's not just an issue you get > past but more of an issue we as a pluto team need to think about. Unfortunately, I only half understand what you say here. I think you're right that its to do with the TLD. I'm not aware of a jar containing the tlds -- in my test environment they are in directory "test/portal/WEB-INF/tld", which contains two files: "pluto.tld" and "portlet.tld". I'm also not sure what you mean by "the taglib jar which is included in common along with the container libraries" (I'm still pretty new to the details of servlets, so there are certainly gaps between what I know and what I should know here). On closer examination of the stack at the point of the exception (repeated here for convenience) >> [[ >> Nested Exception is org.apache.jasper.JasperException: The absolute uri: >> http://java.sun.com/portlet cannot be resolved in either web.xml or >> the jar >> files deployed with this application >> ]] I find: The first occurrence of "http://java.sun.com/portlet"; that I see is this: uri= "http://java.sun.com/portlet"; in org.apache.jasper.compiler.Parser. The code is at line 418, in the call of addTagLib about here: [[ if (pageInfo.getTaglib(uri) == null) { String[] location = ctxt.getTldLocation(uri); pageInfo.addTaglib(uri, new TagLibraryInfoImpl(ctxt, parserController, prefix, uri, location, err)); } ]] The value of uri is determined somewhere in this code: [[ Attributes attrs = parseAttributes(); String uri = attrs.getValue("uri"); String prefix = attrs.getValue("prefix"); if (prefix != null) { Mark prevMark = pageInfo.getNonCustomTagPrefix(prefix); if (prevMark != null) { err.jspError(reader.mark(), "jsp.error.prefix.use_before_dcl", prefix, prevMark.getFile(), "" + prevMark.getLineNumber()); } if (uri != null) { String uriPrev = pageInfo.getURI(prefix); if (uriPrev != null && !uriPrev.equals(uri)) { err.jspError(reader.mark(), "jsp.error.prefix.refined", prefix, uri, uriPrev); } ]] The line: String uri = attrs.getValue("uri"); returns uri= "http://java.sun.com/portlet"; It appears to be processing file introduction.jsp at this point, and I note that this contains: [[ <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c" %> <%@ taglib uri="http://java.sun.com/portlet"; prefix="portlet"%> <portlet:defineObjects/> ]] So it appears that "http://java.sun.com/portlet"; is a reasonable resource to be looking for here. I'm digging around the running installation to see if I can find a candidate for this. The only possibility I find is portlet.tld irtself, which is deployed into directory /pluto/WEB-INF/tld. Further, the file /pluto/WEB-INF/web.xml contains: [[ <taglib> <taglib-uri>http://java.sun.com/portlet</taglib-uri> <taglib-location>/WEB-INF/tld/portlet.tld</taglib-location> </taglib> ]] But I note that the file being processed here is "testsuite/jsp/introduction.jsp", so I guess that somehow the system is now failing to see tag library definitions in the pluto web application directory. To test this, I'll copy the files and web.xml entry into /testsuite. No joy there, so I'll transfer the <taglib> entries into testsuite/WEB-INF/web.xml. Success! (I still need to examine the content in some more detail to confirm that the rendered content is correct, but I'm no longer getting the portlet exception and a previous problem with the test result seems to be overcome. This isn't pretty, but it does suggest to me that the information needed to access tag libraries in the pluto web application area is not being passed to the servlet that runs the portlet. (How is this information usually passed to the portlet servlet context?) #g -- Graham Klyne Research Technology Service Oxford University Computing Services
