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 Serge Huber <sh...@jahia.com> on 2008/11/10 10:37:24 UTC
Bug in setPortletMode() implementation ?
Hi all,
I am in the process of integrating Pluto 2.0 into our portal system,
and while doing some testing, I seem to have run across a bug, but as
I am not an expert yet on the codebase nor the specification, I wanted
to check first.
Basically I have a portlet available in the Portlet Repository :
http://wiki.java.net/bin/view/OpenPortal/BookmarkPortlet that does a
call to setPortletMode. It makes a call to the VIEW mode. This fails
because currently in the following class :
plutocontainer/src/main/java/org/apache/pluto/internal/impl/StateAwareReponseImpl.java
we do the following check :
protected boolean isPortletModeAllowed(PortletMode mode) {
return isPortletModeAllowedByPortlet(mode)
&& isPortletModeAllowedByPortal(mode);
}
Looking at isPortletModeAllowedByPortlet, it seems to check what is
explicitely in the portlet.xml file, forgetting that the VIEW mode
should be present implicitely.
Checking the specification, I read the folllowing :
Portlets must describe within their definition, in the deployment
descriptor, the portlet
modes they can handle for each markup type they support in the render
method. As all
portlets must support the VIEW portlet mode, VIEW does not have to be
indicated.liii The
portlet must not be invoked in a portlet mode that has not been
declared as supported for
30
a given markup type.liv
I'm working with the RI code base, but from what I could see even the
latest trunk also has this problem. This was missed also because the
TCK testsuite portlet doesn't seem to have a test for this.
Did I identify this issue properly ?
Thanks and best regards,
Serge Huber.
Re: Bug in setPortletMode() implementation ?
Posted by Vivek Kumar <fi...@gmail.com>.
Hi
I have Fixed this issue.
Regards
Vivek
CDoremus@hannaford.com wrote:
> Serge,
>
> Thank you for pointing this out. Can you submit a Jira issue on this
> against Pluto-2.0.0? A patch file would also be very welcome.
> /Craig
>
>
>
>
> "Serge Huber"
> <shuber2@jahia.co
> m> To
> Sent by: pluto-dev@portals.apache.org
> bhillou@gmail.com cc
>
> Subject
> 11/10/2008 04:37 Bug in setPortletMode()
> AM implementation ?
>
>
> Please respond to
> pluto-dev@portals
> .apache.org
>
>
>
>
>
>
> Hi all,
>
> I am in the process of integrating Pluto 2.0 into our portal system,
> and while doing some testing, I seem to have run across a bug, but as
> I am not an expert yet on the codebase nor the specification, I wanted
> to check first.
>
> Basically I have a portlet available in the Portlet Repository :
> http://wiki.java.net/bin/view/OpenPortal/BookmarkPortlet that does a
> call to setPortletMode. It makes a call to the VIEW mode. This fails
> because currently in the following class :
>
> plutocontainer/src/main/java/org/apache/pluto/internal/impl/StateAwareReponseImpl.java
>
>
> we do the following check :
>
> protected boolean isPortletModeAllowed(PortletMode mode) {
> return isPortletModeAllowedByPortlet(mode)
> && isPortletModeAllowedByPortal(mode);
> }
>
> Looking at isPortletModeAllowedByPortlet, it seems to check what is
> explicitely in the portlet.xml file, forgetting that the VIEW mode
> should be present implicitely.
>
> Checking the specification, I read the folllowing :
>
> Portlets must describe within their definition, in the deployment
> descriptor, the portlet
> modes they can handle for each markup type they support in the render
> method. As all
> portlets must support the VIEW portlet mode, VIEW does not have to be
> indicated.liii The
> portlet must not be invoked in a portlet mode that has not been
> declared as supported for
> 30
> a given markup type.liv
>
> I'm working with the RI code base, but from what I could see even the
> latest trunk also has this problem. This was missed also because the
> TCK testsuite portlet doesn't seem to have a test for this.
>
> Did I identify this issue properly ?
>
> Thanks and best regards,
> Serge Huber.
>
>
>
Re: Bug in setPortletMode() implementation ?
Posted by CD...@hannaford.com.
Serge,
Thank you for pointing this out. Can you submit a Jira issue on this
against Pluto-2.0.0? A patch file would also be very welcome.
/Craig
"Serge Huber"
<shuber2@jahia.co
m> To
Sent by: pluto-dev@portals.apache.org
bhillou@gmail.com cc
Subject
11/10/2008 04:37 Bug in setPortletMode()
AM implementation ?
Please respond to
pluto-dev@portals
.apache.org
Hi all,
I am in the process of integrating Pluto 2.0 into our portal system,
and while doing some testing, I seem to have run across a bug, but as
I am not an expert yet on the codebase nor the specification, I wanted
to check first.
Basically I have a portlet available in the Portlet Repository :
http://wiki.java.net/bin/view/OpenPortal/BookmarkPortlet that does a
call to setPortletMode. It makes a call to the VIEW mode. This fails
because currently in the following class :
plutocontainer/src/main/java/org/apache/pluto/internal/impl/StateAwareReponseImpl.java
we do the following check :
protected boolean isPortletModeAllowed(PortletMode mode) {
return isPortletModeAllowedByPortlet(mode)
&& isPortletModeAllowedByPortal(mode);
}
Looking at isPortletModeAllowedByPortlet, it seems to check what is
explicitely in the portlet.xml file, forgetting that the VIEW mode
should be present implicitely.
Checking the specification, I read the folllowing :
Portlets must describe within their definition, in the deployment
descriptor, the portlet
modes they can handle for each markup type they support in the render
method. As all
portlets must support the VIEW portlet mode, VIEW does not have to be
indicated.liii The
portlet must not be invoked in a portlet mode that has not been
declared as supported for
30
a given markup type.liv
I'm working with the RI code base, but from what I could see even the
latest trunk also has this problem. This was missed also because the
TCK testsuite portlet doesn't seem to have a test for this.
Did I identify this issue properly ?
Thanks and best regards,
Serge Huber.