You are viewing a plain text version of this content. The canonical link for it is here.
Posted to bridges-dev@portals.apache.org by "Serkan Camurcuoglu (JIRA)" <br...@portals.apache.org> on 2008/05/15 02:23:56 UTC
[jira] Created: (PB-79) defaultCustomPage is not initialized in
FacesPortlet
defaultCustomPage is not initialized in FacesPortlet
----------------------------------------------------
Key: PB-79
URL: https://issues.apache.org/jira/browse/PB-79
Project: Portals Bridges
Issue Type: Bug
Components: jsf
Affects Versions: 1.0.4
Environment: Linux Fedora Core 4, Jetspeed 2.1.3 bundled demo download (Apache Tomcat 5.5.23)
Reporter: Serkan Camurcuoglu
Priority: Minor
FacesPortlet extends GenericServletPortlet, but it declares the defaultActionPage, defaultCustomPage, defaultEditPage, defaultHelpPage and defaultViewPage fields again, therefore these fields hide the fields in GenericServletPortlet. In the constructor of FacesPortlet, only defaultEditPage, defaultViewPage and defaultHelpPage are initialized, the defaultActionPage and defaultCustomPage fields are not initialized, and they are set to defaultViewPage since they are null. In fact, the superclass initializes all these fields, but since the fields are duplicated, this has no effect.
Therefore, the user cannot set the value of defaultCustomPage using portlet.xml. I found a workaround for this problem (by extending FacesPortlet and calling super.init() twice first with a different mock PortletConfig and then the real PortletConfig), but this is not a good and sustainable solution. Note that the same problem also exists for the defaultActionPage. I believe that these fields should not be duplicated in FacesPortlet since GenericServletPortlet provides public setters and getters for all these fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Work started: (PB-79) defaultCustomPage is not initialized
in FacesPortlet
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on PB-79 started by David Sean Taylor.
> defaultCustomPage is not initialized in FacesPortlet
> ----------------------------------------------------
>
> Key: PB-79
> URL: https://issues.apache.org/jira/browse/PB-79
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: Linux Fedora Core 4, Jetspeed 2.1.3 bundled demo download (Apache Tomcat 5.5.23)
> Reporter: Serkan Camurcuoglu
> Assignee: David Sean Taylor
> Priority: Minor
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> FacesPortlet extends GenericServletPortlet, but it declares the defaultActionPage, defaultCustomPage, defaultEditPage, defaultHelpPage and defaultViewPage fields again, therefore these fields hide the fields in GenericServletPortlet. In the constructor of FacesPortlet, only defaultEditPage, defaultViewPage and defaultHelpPage are initialized, the defaultActionPage and defaultCustomPage fields are not initialized, and they are set to defaultViewPage since they are null. In fact, the superclass initializes all these fields, but since the fields are duplicated, this has no effect.
> Therefore, the user cannot set the value of defaultCustomPage using portlet.xml. I found a workaround for this problem (by extending FacesPortlet and calling super.init() twice first with a different mock PortletConfig and then the real PortletConfig), but this is not a good and sustainable solution. Note that the same problem also exists for the defaultActionPage. I believe that these fields should not be duplicated in FacesPortlet since GenericServletPortlet provides public setters and getters for all these fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Assigned: (PB-79) defaultCustomPage is not initialized in
FacesPortlet
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Sean Taylor reassigned PB-79:
-----------------------------------
Assignee: David Sean Taylor
> defaultCustomPage is not initialized in FacesPortlet
> ----------------------------------------------------
>
> Key: PB-79
> URL: https://issues.apache.org/jira/browse/PB-79
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: Linux Fedora Core 4, Jetspeed 2.1.3 bundled demo download (Apache Tomcat 5.5.23)
> Reporter: Serkan Camurcuoglu
> Assignee: David Sean Taylor
> Priority: Minor
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> FacesPortlet extends GenericServletPortlet, but it declares the defaultActionPage, defaultCustomPage, defaultEditPage, defaultHelpPage and defaultViewPage fields again, therefore these fields hide the fields in GenericServletPortlet. In the constructor of FacesPortlet, only defaultEditPage, defaultViewPage and defaultHelpPage are initialized, the defaultActionPage and defaultCustomPage fields are not initialized, and they are set to defaultViewPage since they are null. In fact, the superclass initializes all these fields, but since the fields are duplicated, this has no effect.
> Therefore, the user cannot set the value of defaultCustomPage using portlet.xml. I found a workaround for this problem (by extending FacesPortlet and calling super.init() twice first with a different mock PortletConfig and then the real PortletConfig), but this is not a good and sustainable solution. Note that the same problem also exists for the defaultActionPage. I believe that these fields should not be duplicated in FacesPortlet since GenericServletPortlet provides public setters and getters for all these fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Resolved: (PB-79) defaultCustomPage is not initialized in
FacesPortlet
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Sean Taylor resolved PB-79.
---------------------------------
Resolution: Fixed
> defaultCustomPage is not initialized in FacesPortlet
> ----------------------------------------------------
>
> Key: PB-79
> URL: https://issues.apache.org/jira/browse/PB-79
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: Linux Fedora Core 4, Jetspeed 2.1.3 bundled demo download (Apache Tomcat 5.5.23)
> Reporter: Serkan Camurcuoglu
> Assignee: David Sean Taylor
> Priority: Minor
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> FacesPortlet extends GenericServletPortlet, but it declares the defaultActionPage, defaultCustomPage, defaultEditPage, defaultHelpPage and defaultViewPage fields again, therefore these fields hide the fields in GenericServletPortlet. In the constructor of FacesPortlet, only defaultEditPage, defaultViewPage and defaultHelpPage are initialized, the defaultActionPage and defaultCustomPage fields are not initialized, and they are set to defaultViewPage since they are null. In fact, the superclass initializes all these fields, but since the fields are duplicated, this has no effect.
> Therefore, the user cannot set the value of defaultCustomPage using portlet.xml. I found a workaround for this problem (by extending FacesPortlet and calling super.init() twice first with a different mock PortletConfig and then the real PortletConfig), but this is not a good and sustainable solution. Note that the same problem also exists for the defaultActionPage. I believe that these fields should not be duplicated in FacesPortlet since GenericServletPortlet provides public setters and getters for all these fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-79) defaultCustomPage is not initialized in
FacesPortlet
Posted by "David Sean Taylor (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610625#action_12610625 ]
David Sean Taylor commented on PB-79:
-------------------------------------
A committed a fix. Made the base class data members protected and removed the derived declarations:
http://svn.apache.org/viewvc?rev=674094&view=rev
Please let me know if this works for you
> defaultCustomPage is not initialized in FacesPortlet
> ----------------------------------------------------
>
> Key: PB-79
> URL: https://issues.apache.org/jira/browse/PB-79
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: Linux Fedora Core 4, Jetspeed 2.1.3 bundled demo download (Apache Tomcat 5.5.23)
> Reporter: Serkan Camurcuoglu
> Assignee: David Sean Taylor
> Priority: Minor
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> FacesPortlet extends GenericServletPortlet, but it declares the defaultActionPage, defaultCustomPage, defaultEditPage, defaultHelpPage and defaultViewPage fields again, therefore these fields hide the fields in GenericServletPortlet. In the constructor of FacesPortlet, only defaultEditPage, defaultViewPage and defaultHelpPage are initialized, the defaultActionPage and defaultCustomPage fields are not initialized, and they are set to defaultViewPage since they are null. In fact, the superclass initializes all these fields, but since the fields are duplicated, this has no effect.
> Therefore, the user cannot set the value of defaultCustomPage using portlet.xml. I found a workaround for this problem (by extending FacesPortlet and calling super.init() twice first with a different mock PortletConfig and then the real PortletConfig), but this is not a good and sustainable solution. Note that the same problem also exists for the defaultActionPage. I believe that these fields should not be duplicated in FacesPortlet since GenericServletPortlet provides public setters and getters for all these fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org
[jira] Commented: (PB-79) defaultCustomPage is not initialized in
FacesPortlet
Posted by "Serkan Camurcuoglu (JIRA)" <br...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/PB-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613365#action_12613365 ]
Serkan Camurcuoglu commented on PB-79:
--------------------------------------
Hi David,
I'm sorry but since I've switched to Wicket for portlet development, I don't have the environment to test this patch easily now. I've looked at the code and it seems ok, but I can't perform a real test now, hope this is not a problem for you.
Regards,
> defaultCustomPage is not initialized in FacesPortlet
> ----------------------------------------------------
>
> Key: PB-79
> URL: https://issues.apache.org/jira/browse/PB-79
> Project: Portals Bridges
> Issue Type: Bug
> Components: jsf
> Affects Versions: 1.0.4
> Environment: Linux Fedora Core 4, Jetspeed 2.1.3 bundled demo download (Apache Tomcat 5.5.23)
> Reporter: Serkan Camurcuoglu
> Assignee: David Sean Taylor
> Priority: Minor
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> FacesPortlet extends GenericServletPortlet, but it declares the defaultActionPage, defaultCustomPage, defaultEditPage, defaultHelpPage and defaultViewPage fields again, therefore these fields hide the fields in GenericServletPortlet. In the constructor of FacesPortlet, only defaultEditPage, defaultViewPage and defaultHelpPage are initialized, the defaultActionPage and defaultCustomPage fields are not initialized, and they are set to defaultViewPage since they are null. In fact, the superclass initializes all these fields, but since the fields are duplicated, this has no effect.
> Therefore, the user cannot set the value of defaultCustomPage using portlet.xml. I found a workaround for this problem (by extending FacesPortlet and calling super.init() twice first with a different mock PortletConfig and then the real PortletConfig), but this is not a good and sustainable solution. Note that the same problem also exists for the defaultActionPage. I believe that these fields should not be duplicated in FacesPortlet since GenericServletPortlet provides public setters and getters for all these fields.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: bridges-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: bridges-dev-help@portals.apache.org