[
https://issues.apache.org/jira/browse/PLUTO-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gonzalo Aguilar updated PLUTO-567:
----------------------------------
Attachment: PLUTO-567-verbose-output.patch
Created a new version:
- PortletContainerImpl.java
>Guarding against a null PortletWindow during (only render!) should not be
>needed: it is the responsibility of the invoking Portal to >ensure required
>parameters are provided, otherwise don't call the container. So this change is
>not OK.
Yes! You are Right. Not needed. Will take care PortletRenderTag.
- PortletTag.java
>Change seems OK to me, except a more descriptive message, like mentioning the
>portletId for the non-available portlet, should be >provided.
>Also, strip out the FIXME comment.
Done, Looks much better
- PortletModeDropDownTag.java
>Seems OK too, however the FIXME comment should be replaced with a better
>description why the exception is ignored.
Done
- PortletTitleTag.java
Looks OK, maybe replace "[Unknown]" with "[Unknown -
"+parentTag.getPortletId()+"]"
> Done
> Make Pluto work even if main portlets are not available.
> --------------------------------------------------------
>
> Key: PLUTO-567
> URL: https://issues.apache.org/jira/browse/PLUTO-567
> Project: Pluto
> Issue Type: Bug
> Reporter: Gonzalo Aguilar
> Fix For: 2.0.1
>
> Attachments: handle-config-and-portlet-missing.patch,
> PLUTO-567-patch-cleaned-up.patch, PLUTO-567-verbose-output.patch
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Pluto stops when a portlet is not available to the container.
> A small patch will be provided to let the container run even if no portlets
> are available.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
