[
https://issues.apache.org/jira/browse/PLUTO-664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vernon Singleton updated PLUTO-664:
-----------------------------------
Description:
Steps to reproduce:
1) deploy the tck V2RequestTests war
2) run Pluto in a debugger
3) set a break point in the processAction method for the
V2RequestTests_ClientDataRequest_ApiAction_getPortletInputStream2 test case to
see which method throws the exception (line 132 in master [as of this
post|https://github.com/apache/portals-pluto/blob/0efe7097e62f8c8e752dc64102fa8004c4ebd55a/portlet-tck_3.0/V2RequestTests/src/main/java/javax/portlet/tck/portlets/RequestTests_ClientDataRequest_ApiAction.java#L132])
4) run the V2RequestTests_ClientDataRequest_ApiAction_getPortletInputStream2
test
Expected results:
(/) - getPortletInputStream should be the method that throws an
IllegalStateException and the test should pass for that reason.
(x) - the first call to getReader throws an IllegalStateException causing the
test to pass on Pluto for the wrong reason.
Also, if you look at the V2RequestTests_ClientDataRequest_ApiAction_getReader2
test case in the processAction method, it should call getPortletInputStream
first, and then call getReader second, and only then throw an
IllegalStateException, but there is no call to getReader at all in the test see
lines 249 thru 264 [as of this
post|https://github.com/apache/portals-pluto/blob/0efe7097e62f8c8e752dc64102fa8004c4ebd55a/portlet-tck_3.0/V2RequestTests/src/main/java/javax/portlet/tck/portlets/RequestTests_ClientDataRequest_ApiAction.java#L249-L264]
Yet, the V2RequestTests_ClientDataRequest_ApiAction_getReader2 also passes on
Pluto when it throws an IllegalStateException after simply calling
getPortletInputStream, again never calling getReader as it should.
The main issue with both of these tests is that an IllegalStateException will
always be thrown by either getReader or getPortletInputStream when the enctype
of the submitted form is application/x-www-form-urlencoded, which is the
default for tests in the TCK as of now.
Please look for my suggested fix for these tests below.
was:
Steps to reproduce:
1) deploy the tck V2RequestTests war
2) run Pluto in a debugger
3) set a break point in the processAction method for the
V2RequestTests_ClientDataRequest_ApiAction_getPortletInputStream2 test case to
see which method throws the exception (line 132 in master [as of this
post|https://github.com/apache/portals-pluto/blob/0efe7097e62f8c8e752dc64102fa8004c4ebd55a/portlet-tck_3.0/V2RequestTests/src/main/java/javax/portlet/tck/portlets/RequestTests_ClientDataRequest_ApiAction.java#L132])
4) run the V2RequestTests_ClientDataRequest_ApiAction_getPortletInputStream2
test
Expected results:
(/) - getPortletInputStream should be the method that throws an
IllegalStateException and the test should pass for that reason.
(x) - the first call to getReader throws an IllegalStateException causing the
test to pass on Pluto for the wrong reason.
Also, if you look at the V2RequestTests_ClientDataRequest_ApiAction_getReader2
test case in the processAction method, it should call getPortletInputStream
first, and then call getReader second, and only then throw an
IllegalStateException, but there is no call to getReader at all in the test see
lines 249 thru 264 [as of this
post|https://github.com/apache/portals-pluto/blob/0efe7097e62f8c8e752dc64102fa8004c4ebd55a/portlet-tck_3.0/V2RequestTests/src/main/java/javax/portlet/tck/portlets/RequestTests_ClientDataRequest_ApiAction.java#L249-L264]
Yet, the V2RequestTests_ClientDataRequest_ApiAction_getReader2 also passes on
Pluto when it throws an IllegalStateException after simply calling
getPortletInputStream, again never calling getReader as it should.
The main issue with both of these tests is that an IllegalStateException will
always be thrown when the enctype of the submitted form is
application/x-www-form-urlencoded, which is the default for tests in the TCK as
of now.
Please look for my suggested fix for these tests below.
> TCK: Contesting V2RequestTests_ClientDataRequest_ApiAction_getReader2 and
> _getPortletInputStream2
> -------------------------------------------------------------------------------------------------
>
> Key: PLUTO-664
> URL: https://issues.apache.org/jira/browse/PLUTO-664
> Project: Pluto
> Issue Type: Bug
> Components: tck
> Affects Versions: 3.0.0
> Reporter: Vernon Singleton
> Assignee: Scott Nicklous
>
> Steps to reproduce:
> 1) deploy the tck V2RequestTests war
> 2) run Pluto in a debugger
> 3) set a break point in the processAction method for the
> V2RequestTests_ClientDataRequest_ApiAction_getPortletInputStream2 test case
> to see which method throws the exception (line 132 in master [as of this
> post|https://github.com/apache/portals-pluto/blob/0efe7097e62f8c8e752dc64102fa8004c4ebd55a/portlet-tck_3.0/V2RequestTests/src/main/java/javax/portlet/tck/portlets/RequestTests_ClientDataRequest_ApiAction.java#L132])
> 4) run the V2RequestTests_ClientDataRequest_ApiAction_getPortletInputStream2
> test
> Expected results:
> (/) - getPortletInputStream should be the method that throws an
> IllegalStateException and the test should pass for that reason.
> (x) - the first call to getReader throws an IllegalStateException causing the
> test to pass on Pluto for the wrong reason.
> Also, if you look at the
> V2RequestTests_ClientDataRequest_ApiAction_getReader2 test case in the
> processAction method, it should call getPortletInputStream first, and then
> call getReader second, and only then throw an IllegalStateException, but
> there is no call to getReader at all in the test see lines 249 thru 264 [as
> of this
> post|https://github.com/apache/portals-pluto/blob/0efe7097e62f8c8e752dc64102fa8004c4ebd55a/portlet-tck_3.0/V2RequestTests/src/main/java/javax/portlet/tck/portlets/RequestTests_ClientDataRequest_ApiAction.java#L249-L264]
> Yet, the V2RequestTests_ClientDataRequest_ApiAction_getReader2 also passes on
> Pluto when it throws an IllegalStateException after simply calling
> getPortletInputStream, again never calling getReader as it should.
> The main issue with both of these tests is that an IllegalStateException will
> always be thrown by either getReader or getPortletInputStream when the
> enctype of the submitted form is application/x-www-form-urlencoded, which is
> the default for tests in the TCK as of now.
> Please look for my suggested fix for these tests below.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
