Furthermore, a JSP developer must refer to the tag library using the uri format in the jsp:
<%@ taglib uri="http://java.sun.com/portlet"; prefix="portlet" %>
I think this means:
The container must copy a portlet tag library descriptor (TLD) file (e.g. portlet.tld) to WEB-INF or a subdirectory thereof, or embedded in a jar somewhere under META-INF and then put in WEB-INF/lib.
To allow the jsp container to find the TLD two solutions are possible: add a taglib entry in web.xml mapping the above uri to the TLD, or specifing the uri within the TLD. In the last case the jsp container will be able to find the TLD automatically (see JSP 1.2 spec 7.3.1).
A portlet developer should *not* supply a portlet tag library descriptor itself in the war!
Currently, J2 doesn't do this, it relies on the proper (e.g. J2 specific) TLD be supplied in the war.
I've looked at the Pluto Deployer and it does it as specified. It copies a portlet.tld (defining the above uri) to WEB-INF/tld (the preferred 'standard' location).
Also, it checks all the jsp files contained within the WAR if they refer to a TLD named WEB-INF/tld/portlet.tld, and puts out a warning if it finds one. This is done I think because the Pluto Deployer will *overwrite* the referred TLD with its own!
This check isn't complete though: the web.xml might also map to a such named TLD leading to the same problem. Note though: a developer is allowed by the spec to *override* the container specific TLD by referring to another in web.xml using the same uri (see jsp 1.2 7.3.9). I'm not sure but overriding the TLD by the deployer in that case might be against the specs.
I suggest we should do the same for J2:
- store only one J2 portlet.tld in jetspeed/WEB-INF/tld/.
- add the required uri to the portlet.tld
- let the FileSytemPAM copy it to an expanded portlet application in WEB-INF/tld
- change all our own jsp files referring to the portlet.tld to use the, by the spec required, usage.
- remove all other portlet.tld files from the portlet applications
- optionally add some sanity checks (like Pluto does) against conflicting taglib usage
David Sean Taylor wrote:
On Aug 6, 2004, at 5:36 PM, Jeremy Boynes wrote:
David Sean Taylor wrote:
Im running the Pluto Test Suite on J2 and getting pretty close to passing the tests.
One problem I can't seem to figure out:
In all the JSP pages in the Test Suite, the Portlet API taglib is referenced as:
<%@ taglib uri='http://java.sun.com/portlet' prefix='portlet' %>
This fails on J2, but not on Pluto.
When I point my browser at http://java.sun.com/portlet, the page is not found
If I replace the taglib with
<%@ taglib uri='/WEB-INF/tld/portlet.tld' prefix='portlet' %>
then I can run the test suite.
Any ideas on how Pluto gets past this bad URL?
Scott -- just wanted to point out that I once I replace the taglibs, deploying this PA is as simple as dropping it in!
This isn't really a bad URL, it is just a URI that uniquely identifies the taglib.
Pluto is generating a Servlet 2.3 web.xml with <taglib> elements that map the URI to the physical location. I don't know what it does if it sees a Servlet 2.4 web.xml file (it would need to generate <jsp-config> elements instead).
Does J2 use the Pluto deployer? If not, it could just be that the J2 portlet deployer needs to add these elements as well.
J2 uses a different deployer. I'll give that a try, thanks
-- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773-4646 [mobile] +01 707 529 9194
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
