[
https://issues.apache.org/jira/browse/PLUTO-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Nicklous updated PLUTO-642:
---------------------------------
Component/s: portlet container
Description:
Failing test cases:
1) TestModule3_PublicRenderParameterTestDifferentQName
2) TestModule3_PublicRenderParameterTestDifferentIdentifier
The QName is supposed to uniquely identify a public render parameter, while the
identifier is string used within the portlet to address the PRP through the
parameter handling APIs. This implies that the comparison as to whether two
portlets use the same PRP should be done on the basis of the QName rather than
on the basis of the local identifier.
Test 1) above uses two portlets that use the same PRP identifiers, but
different QNames.
Expected behavior: The portal does not consider the PRPs to be the same.
Pluto results: The PRPs are considered to be the same.
Test 2) above uses two portlets that use the same QNames, but different
identifiers.
Expected behavior: The portal considers the PRPs to be the same.
Pluto results: The PRPs are not considered to be the same.
Note that if both the QName and the identifier are the same, Pluto correctly
considers the PRPs of both portlets to be the same.
The conclusion is that Pluto performs the PRP matching based on the identifier
rather than on the QName. This is in my view incorrect.
was:
Failing test cases:
1) TestModule3_PublicRenderParameterTestDifferentQName
2) TestModule3_PublicRenderParameterTestDifferentIdentifier
The QName is supposed to uniquely identify a public render parameter, while the
identifier is string used within the portlet to address the PRP through the
parameter handling APIs. This implies that the comparison as to whether two
portlets use the same PRP should be done on the basis of the QName rather than
on the basis of the local identifier.
Test 1) above uses two portlets that use the same PRP identifiers, but
different QNames.
Expected behavior: The portal does not consider the PRPs to be the same.
Pluto results: The PRPs are considered to be the same.
Test 2) above uses two portlets that use the same QNames, but different
identifiers.
Expected behavior: The portal considers the PRPs to be the same.
Pluto results: The PRPs are not considered to be the same.
The conclusion is that Pluto performs the PRP matching based on the identifier
rather than on the QName. This is in my view incorrect.
Affects Version/s: 2.1.0-M3
> TCK: The QName seems to be ignored during Public Render Parameter processing
> ----------------------------------------------------------------------------
>
> Key: PLUTO-642
> URL: https://issues.apache.org/jira/browse/PLUTO-642
> Project: Pluto
> Issue Type: Bug
> Components: portlet container
> Affects Versions: 2.1.0-M3
> Reporter: Scott Nicklous
>
> Failing test cases:
> 1) TestModule3_PublicRenderParameterTestDifferentQName
> 2) TestModule3_PublicRenderParameterTestDifferentIdentifier
> The QName is supposed to uniquely identify a public render parameter, while
> the identifier is string used within the portlet to address the PRP through
> the parameter handling APIs. This implies that the comparison as to whether
> two portlets use the same PRP should be done on the basis of the QName rather
> than on the basis of the local identifier.
> Test 1) above uses two portlets that use the same PRP identifiers, but
> different QNames.
> Expected behavior: The portal does not consider the PRPs to be the same.
> Pluto results: The PRPs are considered to be the same.
> Test 2) above uses two portlets that use the same QNames, but different
> identifiers.
> Expected behavior: The portal considers the PRPs to be the same.
> Pluto results: The PRPs are not considered to be the same.
> Note that if both the QName and the identifier are the same, Pluto correctly
> considers the PRPs of both portlets to be the same.
> The conclusion is that Pluto performs the PRP matching based on the
> identifier rather than on the QName. This is in my view incorrect.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
