portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject Re: Pluto Test Suite
Date Sat, 07 Aug 2004 20:22:21 GMT
The specs (PLT.22) says the portlet container must provide an implementation of 
the tag library.
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
> david@bluesunrise.com
> [office]   +01 707 773-4646
> [mobile] +01 707 529 9194
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
> 
> 
> 
> 


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


Mime
View raw message