You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by David Sean Taylor <da...@bluesunrise.com> on 2004/08/06 22:35:42 UTC
Pluto Test Suite
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!
--
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
Re: Pluto Test Suite
Posted by Ate Douma <at...@douma.nu>.
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
Re: Pluto Test Suite
Posted by David Sean Taylor <da...@bluesunrise.com>.
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
Re: Pluto Test Suite
Posted by Jeremy Boynes <jb...@gluecode.com>.
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.
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Pluto Test Suite
Posted by "Scott T. Weaver" <sc...@binary-designs.net>.
Awesome! Thanks David for getting the Testsuite passing!
David Sean Taylor wrote:
>
> The test seems to be passing for me now, at least I don't see any RED
> failed messages anywhere
>
> To summarize, it still requires 2 modifications to pass:
>
> 1. in all JSP files replace
>
> <%@ taglib uri='http://java.sun.com/portlet' prefix='portlet' %>
> with
> <%@ taglib uri='/WEB-INF/tld/portlet.tld' prefix='portlet' %>
>
> 2. In the expectedResults.properties found in the
> WEB-INF/classes/expectedResults.properties file, replace
>
> expected.portalInfo = Pluto/1.0
>
> with
>
> expected.portalInfo = Jetspeed/2.0
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>
>
--
******************************************
* Scott T. Weaver *
* <we...@apache.org> *
* <http://www.einnovation.com> *
* -------------------------------------- *
* Apache Jetspeed Enterprise Portal *
* Apache Pluto Portlet Container *
* *
* OpenEditPro, Website Content Mangement *
* <http://www.openeditpro.com> *
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Pluto Test Suite
Posted by David Sean Taylor <da...@bluesunrise.com>.
The test seems to be passing for me now, at least I don't see any RED
failed messages anywhere
To summarize, it still requires 2 modifications to pass:
1. in all JSP files replace
<%@ taglib uri='http://java.sun.com/portlet' prefix='portlet' %>
with
<%@ taglib uri='/WEB-INF/tld/portlet.tld' prefix='portlet' %>
2. In the expectedResults.properties found in the
WEB-INF/classes/expectedResults.properties file, replace
expected.portalInfo = Pluto/1.0
with
expected.portalInfo = Jetspeed/2.0
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
Re: Pluto Test Suite
Posted by David Sean Taylor <da...@bluesunrise.com>.
On Aug 6, 2004, at 1:35 PM, David Sean Taylor wrote:
>
> Scott -- just wanted to point out that I once I replace the taglibs,
> deploying this PA is as simple as dropping it in!
>
Forgot to mention, there is already a page for the test suite.
Just drop testsuite.war it into the WEB-INF/deploy directory and go to:
http://localhost:8080/jetspeed/portal/testsuite/
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org