You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pluto-dev@portals.apache.org by "Vernon Singleton (JIRA)" <ji...@apache.org> on 2017/05/16 03:53:04 UTC

[jira] [Commented] (PLUTO-659) TCK: Contesting V2AddlFilterTests_SPEC2_20_Action_filter1

    [ https://issues.apache.org/jira/browse/PLUTO-659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16011696#comment-16011696 ] 

Vernon Singleton commented on PLUTO-659:
----------------------------------------

Here is a PR to ignore the test case for now:
https://github.com/apache/portals-pluto/pull/17


> TCK: Contesting V2AddlFilterTests_SPEC2_20_Action_filter1
> ---------------------------------------------------------
>
>                 Key: PLUTO-659
>                 URL: https://issues.apache.org/jira/browse/PLUTO-659
>             Project: Pluto
>          Issue Type: Bug
>          Components: tck
>    Affects Versions: 3.0.0
>            Reporter: Vernon Singleton
>            Assignee: Scott Nicklous
>
> According to 4.2.1 Loading and Instantiation:
> {quote}
> The portlet container is responsible for loading and instantiating portlets. The loading and
> instantiation can occur when the portlet container starts the portlet application, or can be
> delayed until the portlet container determines the portlet is needed to service a request.
> {quote}
> According to 16.2.1 Filter Lifecycle section:
> {quote}
> After deployment of the portlet application, and before a request causes the portlet container to access a portlet, the portlet container must build an ordered list of the portlet filters to be applied to the portlet as defined in the portlet configuration. The portlet container must instantiate a filter of the appropriate class for each applicable filter and called the filter init(FilterConfig config) method.
> {quote}
> Since portlet.init() "can be delayed until" a request comes in, but filter.init() must be called "before a request", the TCK should not assume that portlet.init() is called before filter.init() is called.
> Here we can see [the V2AddlFilterTests_SPEC2_20_Action_filter1 test|https://github.com/apache/portals-pluto/blob/8affd336c65fbfe86f78866f60bd4f8af6e7fe93/portlet-tck_3.0/V2AddlFilterTests/src/main/java/javax/portlet/tck/portlets/AddlFilterTests_SPEC2_20_Filter.java#L82-L102] requiring the portletNameAction attribute to be set by portlet.init() before the filter.init() method is called.
> It looks like Pluto is doing its Post/Redirect/Get calling first the portlet.init() in the post, and then later during the get, calling filter.init().  This is fine to do, I guess, but we cannot assume that all portal vendors will use this pattern.
> Here is a thread dump showing pluto calling portlet.init() during the post:
> {code}
> "http-nio-8080-exec-14@9550" daemon prio=5 tid=0x68e nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>       at javax.portlet.tck.portlets.AddlFilterTests_SPEC2_20_Filter.init(AddlFilterTests_SPEC2_20_Filter.java:108)
>       at org.apache.pluto.driver.services.container.FilterChainImpl.doFilter(FilterChainImpl.java:185)
>       at org.apache.pluto.driver.services.container.FilterChainImpl.processFilter(FilterChainImpl.java:153)
>       at org.apache.pluto.driver.services.container.FilterManagerImpl.processFilter(FilterManagerImpl.java:142)
>       at org.apache.pluto.container.driver.PortletServlet3.dispatch(PortletServlet3.java:517)
>       at org.apache.pluto.container.driver.PortletServlet3.doPost(PortletServlet3.java:338)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> {code}
> followed by the call to filter.init() during the get:
> {code}
> "http-nio-8080-exec-13@9531" daemon prio=5 tid=0x68d nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>       at javax.portlet.tck.portlets.AddlFilterTests_SPEC2_20_Filter.init(AddlFilterTests_SPEC2_20_Filter.java:97)
>       at org.apache.pluto.driver.services.container.FilterChainImpl.doFilter(FilterChainImpl.java:233)
>       at org.apache.pluto.driver.services.container.FilterChainImpl.processFilter(FilterChainImpl.java:161)
>       at org.apache.pluto.driver.services.container.FilterManagerImpl.processFilter(FilterManagerImpl.java:126)
>       at org.apache.pluto.container.driver.PortletServlet3.dispatch(PortletServlet3.java:487)
>       at org.apache.pluto.container.driver.PortletServlet3.doGet(PortletServlet3.java:333)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)
>       at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> {code}
> Since it appears that the TCK is testing the pluto implementation in this case instead of testing the specification, and the test case is invalid as defined, I will update the ignore list to include V2AddlFilterTests_SPEC2_20_Action_filter1 and issue a pull request, until a better test can be written.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)