[JBoss JIRA] (GTNPORTAL-2072) NoSuchDataException is thrown after importing pages through export/import tool.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-2072?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-2072:
----------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1038029|https://bugzilla.redhat.com/show_bug.cgi?id=1038029] from ASSIGNED to MODIFIED
> NoSuchDataException is thrown after importing pages through export/import tool.
> -------------------------------------------------------------------------------
>
> Key: GTNPORTAL-2072
> URL: https://issues.jboss.org/browse/GTNPORTAL-2072
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.0-Beta01
> Reporter: Nick Scavelli
> Assignee: Vu Viet Phuong
> Labels: import
> Fix For: 3.6.4.Final, 3.7.0.Final
>
> Original Estimate: 1 day
> Time Spent: 2 days, 6 hours
> Remaining Estimate: 0 minutes
>
> Below exception is thrown after importing pages through management tools (see steps to reproduce section). I think this is a stale storageId coming from the UI when the data has changed outside the UI. Typically logging out solves the issue, but this isn't optimal. Changes to data should not be only achievable through the UI. The changes are being sent through DataStorage, so there should be someway to sync this data up.
> Stacktrace:
> {noformat}
> Caused by: org.exoplatform.portal.config.NoSuchDataException: Can not find 1c42bec77f0000011076449207f5d085
> at org.exoplatform.portal.pom.config.POMSession.findCustomizationById(POMSession.java:214)
> at org.exoplatform.portal.pom.config.tasks.PreferencesTask$Load.run(PreferencesTask.java:91)
> at org.exoplatform.portal.pom.config.POMSession.execute(POMSession.java:405)
> at org.exoplatform.portal.pom.config.ExecutorDispatcher.execute(ExecutorDispatcher.java:60)
> at org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
> at org.exoplatform.portal.pom.config.cache.DataCache.read(DataCache.java:169)
> at org.exoplatform.portal.pom.config.cache.DataCache.execute(DataCache.java:61)
> at org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
> at org.exoplatform.portal.pom.config.cache.PortalNamesCache.execute(PortalNamesCache.java:77)
> at org.exoplatform.portal.pom.config.POMSessionManager.execute(POMSessionManager.java:251)
> at org.exoplatform.portal.pom.config.POMDataStorage.load(POMDataStorage.java:176)
> at org.exoplatform.portal.config.DataStorageImpl.load(DataStorageImpl.java:111)
> at org.exoplatform.portal.webui.application.ModelAdapter$1.getPortletContext(ModelAdapter.java:89)
> at org.exoplatform.portal.webui.application.UIPortlet.getPortletContext(UIPortlet.java:993)
> at org.exoplatform.portal.webui.application.UIPortlet.create(UIPortlet.java:829)
> at org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:212)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (GTNPORTAL-2072) NoSuchDataException is thrown after importing pages through export/import tool.
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-2072?page=com.atlassian.jira.pl... ]
Peter Palaga updated GTNPORTAL-2072:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 3.6.4.Final
3.7.0.Final
Resolution: Done
> NoSuchDataException is thrown after importing pages through export/import tool.
> -------------------------------------------------------------------------------
>
> Key: GTNPORTAL-2072
> URL: https://issues.jboss.org/browse/GTNPORTAL-2072
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.0-Beta01
> Reporter: Nick Scavelli
> Assignee: Vu Viet Phuong
> Labels: import
> Fix For: 3.6.4.Final, 3.7.0.Final
>
> Original Estimate: 1 day
> Time Spent: 2 days, 6 hours
> Remaining Estimate: 0 minutes
>
> Below exception is thrown after importing pages through management tools (see steps to reproduce section). I think this is a stale storageId coming from the UI when the data has changed outside the UI. Typically logging out solves the issue, but this isn't optimal. Changes to data should not be only achievable through the UI. The changes are being sent through DataStorage, so there should be someway to sync this data up.
> Stacktrace:
> {noformat}
> Caused by: org.exoplatform.portal.config.NoSuchDataException: Can not find 1c42bec77f0000011076449207f5d085
> at org.exoplatform.portal.pom.config.POMSession.findCustomizationById(POMSession.java:214)
> at org.exoplatform.portal.pom.config.tasks.PreferencesTask$Load.run(PreferencesTask.java:91)
> at org.exoplatform.portal.pom.config.POMSession.execute(POMSession.java:405)
> at org.exoplatform.portal.pom.config.ExecutorDispatcher.execute(ExecutorDispatcher.java:60)
> at org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
> at org.exoplatform.portal.pom.config.cache.DataCache.read(DataCache.java:169)
> at org.exoplatform.portal.pom.config.cache.DataCache.execute(DataCache.java:61)
> at org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
> at org.exoplatform.portal.pom.config.cache.PortalNamesCache.execute(PortalNamesCache.java:77)
> at org.exoplatform.portal.pom.config.POMSessionManager.execute(POMSessionManager.java:251)
> at org.exoplatform.portal.pom.config.POMDataStorage.load(POMDataStorage.java:176)
> at org.exoplatform.portal.config.DataStorageImpl.load(DataStorageImpl.java:111)
> at org.exoplatform.portal.webui.application.ModelAdapter$1.getPortletContext(ModelAdapter.java:89)
> at org.exoplatform.portal.webui.application.UIPortlet.getPortletContext(UIPortlet.java:993)
> at org.exoplatform.portal.webui.application.UIPortlet.create(UIPortlet.java:829)
> at org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:212)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (GTNPORTAL-2930) Portal keep session alive property values are confusing
by Boleslaw Dawidowicz (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-2930?page=com.atlassian.jira.pl... ]
Boleslaw Dawidowicz updated GTNPORTAL-2930:
-------------------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/gatein/gatein-portal/pull/732
> Portal keep session alive property values are confusing
> -------------------------------------------------------
>
> Key: GTNPORTAL-2930
> URL: https://issues.jboss.org/browse/GTNPORTAL-2930
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.6.0.Beta01
> Reporter: Dominik Pospisil
> Assignee: Tuyen Nguyen The
> Original Estimate: 4 hours
> Time Spent: 4 hours
> Remaining Estimate: 0 minutes
>
> According to documentation, portal "keep seesion alive" property values meaning are as follows:
> never - The session will never timeout, even if an application requests it.
> On-demand - The session will timeout if an application requests it
> Always - The session will time out after a set period
> This is quite confusing. E.g. keep session alive never actually means to keep session alive forever.
> Keep session alive always means to let the session timeout automatically.
> If the documentation is correct, the name of the property or property values should be changed.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months
[JBoss JIRA] (GTNPC-109) Modify EventResponse Interface to preserve window state changes accross multiple event invocations
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPC-109?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on GTNPC-109:
-----------------------------------------------
vramik(a)redhat.com changed the Status of [bug 997036|https://bugzilla.redhat.com/show_bug.cgi?id=997036] from ON_QA to VERIFIED
> Modify EventResponse Interface to preserve window state changes accross multiple event invocations
> --------------------------------------------------------------------------------------------------
>
> Key: GTNPC-109
> URL: https://issues.jboss.org/browse/GTNPC-109
> Project: GateIn Portlet Container
> Issue Type: Enhancement
> Components: API
> Affects Versions: 2.4.1.Final
> Reporter: Adam Kovari
> Priority: Minor
> Fix For: 2.4.3.Final
>
> Attachments: 00905214-src.zip
>
>
> If a portlet changes it's window state in the event processing phase, this state is not preserved as other portlets/events can be processed on the same page and then portal will override this changes.
> The spec says:
> PLT.12.4 EventResponse Interface
> ================================
> The EventResponse interface extends the StateAwareResponse interface and adds the additional method setRenderParameters(EventRequest request). One thing to note is that if a portlet receives multiple processEvent calls while processing one client request the new portlet mode or window state that the portlet may have set, may be not validated by the portal between these multiple processEvent calls. This means that even if the portlet container may not throw an exception when the portlet sets a new portlet mode or window state that the portal may still not approve this portlet mode or window state change and call the portlet render method with a different portlet mode or window state.
> So the window state change can be preserved even accross multiple events invocation. Seems to be fine by the spec as shown above.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 3 months