[JBoss JIRA] (GTNPORTAL-3013) UserProfileDAOImpl not distinguishing creating and updating user profile when firing preSave/postSave events
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3013?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-3013:
----------------------------------------------------
Tomas Kyjovsky <tkyjovsk(a)redhat.com> changed the Status of [bug 947956|https://bugzilla.redhat.com/show_bug.cgi?id=947956] from ON_QA to VERIFIED
> UserProfileDAOImpl not distinguishing creating and updating user profile when firing preSave/postSave events
> ------------------------------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3013
> URL: https://issues.jboss.org/browse/GTNPORTAL-3013
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Identity integration
> Affects Versions: 3.6.0.Beta01
> Reporter: Marek Posolda
> Assignee: Marek Posolda
> Fix For: 3.6.0.Beta02
>
>
> org.exoplatform.services.organization.idm.UserProfileDAOImpl; the following is a code excerpt of the file included in the community version of the Maven artefact org.exoplatform.portal:exo.portal.component.identity:3.3.0-GA
> // void createUserProfileEntry(UserProfile up, IdentitySession session) throws Exception
> // {
> // UserProfileData upd = new UserProfileData();
> // upd.setUserProfile(up);
> // session.save(upd);
> // session.flush();
> // cache_.remove(up.getUserName());
> // }
> public void saveUserProfile(UserProfile profile, boolean broadcast) throws Exception
> {
> if (broadcast)
> {
> preSave(profile, true);
> }
> setProfile(profile.getUserName(), profile);
> if (broadcast)
> {
> postSave(profile, true);
> }
> }
> As you can see, the preSave() method is always called with "true". However, saveUserProfile() is the only available method for persisting UserProfile objects. From the commented-out createUserProfileEntry() method, I draw the conclusion that at some point, there was a distinction between methods to call for new and existing UserProfiles (just as there is for Users in the UserDAOImpl in the same package - there are a createUser() and a saveUser()).
> Where all this breaks down is in the listeners; upon saving the UserProfile, I want to send either a save or an update message over JMS to a SOA-P application that transforms the message and forwards it to a mainframe application that needs to know about user creation and modification. I need to pick the correct message format, but as it turns out, I can't use the isNew parameter to reliably determine which one to choose.
> I have tried to work around the problem by creating the UserProfile first and the User second, and sync from the User Listener, since the User preSave() does receive a correct value for isNew; however, Hibernate won't let me: new UserProfiles can not be saved if the User they are associated with does not yet exist in the database; they are a dependent entity.
> Can you provide a version of the Identity Component that can distinguish between updating and saving UserProfile objects, or a suitable workaround to that end?
> Version-Release number of selected component (if applicable):
> EPP 5
> JPP 6
> How reproducible:
> always
> Steps to Reproduce:
> please see attached customer case
>
> Actual results:
> true as the parameter even with update
> Expected results:
> true/false depending on create or update
> Additional info:
--
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
11 years, 4 months
[JBoss JIRA] (GTNPORTAL-3013) UserProfileDAOImpl not distinguishing creating and updating user profile when firing preSave/postSave events
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3013?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-3013:
----------------------------------------------------
Tomas Kyjovsky <tkyjovsk(a)redhat.com> made a comment on [bug 947956|https://bugzilla.redhat.com/show_bug.cgi?id=947956]
Verified with 6.1.0.ER01.1 and ER04 using a custom UserEventListener.
Creating new user "test":
15:07:08,804 INFO [stdout] (http-/127.0.0.1:8080-1) preSave(user:test, isNew:true)
15:07:08,804 INFO [stdout] (http-/127.0.0.1:8080-1) preSave(user:test, isNew:true)
15:07:08,830 INFO [stdout] (http-/127.0.0.1:8080-1) postSave(user:test, isNew:true)
15:07:08,894 INFO [stdout] (http-/127.0.0.1:8080-1) postSave(user:test, isNew:true)
Updating created user "test":
15:07:18,435 INFO [stdout] (http-/127.0.0.1:8080-1) preSave(user:test, isNew:false)
15:07:18,435 INFO [stdout] (http-/127.0.0.1:8080-1) preSave(user:test, isNew:false)
15:07:18,443 INFO [stdout] (http-/127.0.0.1:8080-1) postSave(user:test, isNew:false)
15:07:18,447 INFO [stdout] (http-/127.0.0.1:8080-1) postSave(user:test, isNew:false)
> UserProfileDAOImpl not distinguishing creating and updating user profile when firing preSave/postSave events
> ------------------------------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3013
> URL: https://issues.jboss.org/browse/GTNPORTAL-3013
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Identity integration
> Affects Versions: 3.6.0.Beta01
> Reporter: Marek Posolda
> Assignee: Marek Posolda
> Fix For: 3.6.0.Beta02
>
>
> org.exoplatform.services.organization.idm.UserProfileDAOImpl; the following is a code excerpt of the file included in the community version of the Maven artefact org.exoplatform.portal:exo.portal.component.identity:3.3.0-GA
> // void createUserProfileEntry(UserProfile up, IdentitySession session) throws Exception
> // {
> // UserProfileData upd = new UserProfileData();
> // upd.setUserProfile(up);
> // session.save(upd);
> // session.flush();
> // cache_.remove(up.getUserName());
> // }
> public void saveUserProfile(UserProfile profile, boolean broadcast) throws Exception
> {
> if (broadcast)
> {
> preSave(profile, true);
> }
> setProfile(profile.getUserName(), profile);
> if (broadcast)
> {
> postSave(profile, true);
> }
> }
> As you can see, the preSave() method is always called with "true". However, saveUserProfile() is the only available method for persisting UserProfile objects. From the commented-out createUserProfileEntry() method, I draw the conclusion that at some point, there was a distinction between methods to call for new and existing UserProfiles (just as there is for Users in the UserDAOImpl in the same package - there are a createUser() and a saveUser()).
> Where all this breaks down is in the listeners; upon saving the UserProfile, I want to send either a save or an update message over JMS to a SOA-P application that transforms the message and forwards it to a mainframe application that needs to know about user creation and modification. I need to pick the correct message format, but as it turns out, I can't use the isNew parameter to reliably determine which one to choose.
> I have tried to work around the problem by creating the UserProfile first and the User second, and sync from the User Listener, since the User preSave() does receive a correct value for isNew; however, Hibernate won't let me: new UserProfiles can not be saved if the User they are associated with does not yet exist in the database; they are a dependent entity.
> Can you provide a version of the Identity Component that can distinguish between updating and saving UserProfile objects, or a suitable workaround to that end?
> Version-Release number of selected component (if applicable):
> EPP 5
> JPP 6
> How reproducible:
> always
> Steps to Reproduce:
> please see attached customer case
>
> Actual results:
> true as the parameter even with update
> Expected results:
> true/false depending on create or update
> Additional info:
--
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
11 years, 4 months
[JBoss JIRA] (GTNPORTAL-3156) NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3156?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration updated GTNPORTAL-3156:
-----------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=984405, https://bugzilla.redhat.com/show_bug.cgi?id=984472 (was: https://bugzilla.redhat.com/show_bug.cgi?id=984405)
> NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()
> --------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3156
> URL: https://issues.jboss.org/browse/GTNPORTAL-3156
> Project: GateIn Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Common integration, WebUI
> Affects Versions: 3.5.3.Final
> Environment: RHEL 5.9 64bits, Oracle/Sun jdk 1.7.0
> Reporter: Regis Mazur
> Priority: Minor
> Fix For: 3.5.3.Final
>
>
> During rendering of portal page an NPE error occurred when the portlet uicomponent try to retrieve theme (UIPortlet.getSuitedTheme() method).
> It can sometimes be reproduced when there are concurrent navigation requests (click around on the nav menu without waiting for a response).
> After investigation, it seems that the uicomponent tree is broken in this case and UIPortalApplication (null in this case) cannot be retrieve via the getAncestorOfType(UIPortalApplication.class) method.
> If you look at the content of uicomponent tree (see the "Expected results" and "Actual results"), you will see that standard portal uicomponent(UIPageBody,UIPortal,UISiteBody,UIViewWS,UIWorkingWorkspace,UIPortalApplication) are not in the tree.
> We reproduced the case in dev environment when there are concurrent navigation requests (click around around the nav menu without waiting for a response).
> It seems to be a concurrency issue in the portal itself.
> For the moment we fix the NPE in the UIPortlet.gtmpl (By retrieving the UIPortalApplication from the RequestContext instead of parsing the full uicomponent tree) but we don't fix the root cause and the possible side effects.
> Version-Release number of selected component (if applicable):
> GateIn 3.5.2.Final-redhat-4
> How reproducible:
> Not always. Mostly while testing within customer test environment where deployed portlets model is more significant in term of size and complexity.
> Steps to Reproduce:
> Actually we tried but we can't reproduce it locally using JSF2.1 Quickstart portlet calling same portlet tree. This only happens when using "full" application which has a lot of other dependencies.
> 1.
> 2.
> 3.
> Actual results:
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : queries
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row1
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : activities
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row2
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : news
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row2
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> Expected results:
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) Looking for UIPortalApplication parent
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : tasks
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : row1
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : pp_portal_Dashboard - id : 22572705
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIPageBody - id : UIPageBody
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : clearstream - id : UIPortal
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UISiteBody - id : UISiteBody
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : 17689309
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIComponentDecorator - id : UIViewWS
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIWorkingWorkspace - id : UIWorkingWorkspace
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIPortalApplication - id : UIPortalApplication
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent found : UIPortalApplication - id : UIPortalApplication
> Additional info:
> We think this caused by uiPortal.getAncestorOfType(UIPortalApplication.class) from UIComponent class which can't get the parent.
> We've got an actual proposed solution which is to use Util.getUIPortalApplication() instead to get the same thing (getSkin).
> Here is below the code snippet used:
> -----------------------
> String theme = null;
>
> try{
> theme = uicomponent.getSuitedTheme(null);
> } catch (RuntimeException e) {
> Map<String, String> themeMap = uicomponent.stringToThemeMap(uicomponent.getTheme());
> if (themeMap.containsKey(uiPortalApp.getSkin())) {
> theme = themeMap.get(uiPortalApp.getSkin());
> }
> else theme= uicomponent.DEFAULT_THEME.split(":")[1];
> }
> ----------------------
> While doing some searches, we found out Exo people have also used similar approach (refer to URL link below).
> http://lists.jboss.org/pipermail/gatein-commits/2010-November/005095.html
> Within Server.log we've got:
> Caused by: java.lang.NullPointerException
> at org.exoplatform.portal.webui.application.UIPortlet.getSuitedTheme(UIPortlet.java:270) [exo.portal.webui.portal-3.5.2.Final-redhat-4.jar:3.5.2.Final-redhat-4]
> at sun.reflect.GeneratedMethodAccessor1549.invoke(Unknown Source) [:1.7.0_06]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_06]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_06]
> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229) [groovy-all-1.7.6.jar:1.7.6]
> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52) [groovy-all-1.7.6.jar:1.7.6]
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) [groovy-all-1.7.6.jar:1.7.6]
> at UIPortlet.run(UIPortlet.gtmpl:96) at org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:99) [exo.portal.component.scripting-3.5.2.Final-redhat-4.jar:3.5.2.Final-redhat-4]
--
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
11 years, 4 months
[JBoss JIRA] (GTNPORTAL-3156) NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()
by Adam Kovari (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3156?page=com.atlassian.jira.pl... ]
Adam Kovari updated GTNPORTAL-3156:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/gatein/gatein-portal/pull/625
> NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()
> --------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3156
> URL: https://issues.jboss.org/browse/GTNPORTAL-3156
> Project: GateIn Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Common integration, WebUI
> Affects Versions: 3.5.3.Final
> Environment: RHEL 5.9 64bits, Oracle/Sun jdk 1.7.0
> Reporter: Regis Mazur
> Priority: Minor
> Fix For: 3.5.3.Final
>
>
> During rendering of portal page an NPE error occurred when the portlet uicomponent try to retrieve theme (UIPortlet.getSuitedTheme() method).
> It can sometimes be reproduced when there are concurrent navigation requests (click around on the nav menu without waiting for a response).
> After investigation, it seems that the uicomponent tree is broken in this case and UIPortalApplication (null in this case) cannot be retrieve via the getAncestorOfType(UIPortalApplication.class) method.
> If you look at the content of uicomponent tree (see the "Expected results" and "Actual results"), you will see that standard portal uicomponent(UIPageBody,UIPortal,UISiteBody,UIViewWS,UIWorkingWorkspace,UIPortalApplication) are not in the tree.
> We reproduced the case in dev environment when there are concurrent navigation requests (click around around the nav menu without waiting for a response).
> It seems to be a concurrency issue in the portal itself.
> For the moment we fix the NPE in the UIPortlet.gtmpl (By retrieving the UIPortalApplication from the RequestContext instead of parsing the full uicomponent tree) but we don't fix the root cause and the possible side effects.
> Version-Release number of selected component (if applicable):
> GateIn 3.5.2.Final-redhat-4
> How reproducible:
> Not always. Mostly while testing within customer test environment where deployed portlets model is more significant in term of size and complexity.
> Steps to Reproduce:
> Actually we tried but we can't reproduce it locally using JSF2.1 Quickstart portlet calling same portlet tree. This only happens when using "full" application which has a lot of other dependencies.
> 1.
> 2.
> 3.
> Actual results:
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : queries
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row1
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : activities
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row2
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : news
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row2
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> Expected results:
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) Looking for UIPortalApplication parent
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : tasks
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : row1
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : pp_portal_Dashboard - id : 22572705
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIPageBody - id : UIPageBody
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : clearstream - id : UIPortal
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UISiteBody - id : UISiteBody
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : 17689309
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIComponentDecorator - id : UIViewWS
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIWorkingWorkspace - id : UIWorkingWorkspace
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIPortalApplication - id : UIPortalApplication
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent found : UIPortalApplication - id : UIPortalApplication
> Additional info:
> We think this caused by uiPortal.getAncestorOfType(UIPortalApplication.class) from UIComponent class which can't get the parent.
> We've got an actual proposed solution which is to use Util.getUIPortalApplication() instead to get the same thing (getSkin).
> Here is below the code snippet used:
> -----------------------
> String theme = null;
>
> try{
> theme = uicomponent.getSuitedTheme(null);
> } catch (RuntimeException e) {
> Map<String, String> themeMap = uicomponent.stringToThemeMap(uicomponent.getTheme());
> if (themeMap.containsKey(uiPortalApp.getSkin())) {
> theme = themeMap.get(uiPortalApp.getSkin());
> }
> else theme= uicomponent.DEFAULT_THEME.split(":")[1];
> }
> ----------------------
> While doing some searches, we found out Exo people have also used similar approach (refer to URL link below).
> http://lists.jboss.org/pipermail/gatein-commits/2010-November/005095.html
> Within Server.log we've got:
> Caused by: java.lang.NullPointerException
> at org.exoplatform.portal.webui.application.UIPortlet.getSuitedTheme(UIPortlet.java:270) [exo.portal.webui.portal-3.5.2.Final-redhat-4.jar:3.5.2.Final-redhat-4]
> at sun.reflect.GeneratedMethodAccessor1549.invoke(Unknown Source) [:1.7.0_06]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_06]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_06]
> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229) [groovy-all-1.7.6.jar:1.7.6]
> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52) [groovy-all-1.7.6.jar:1.7.6]
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) [groovy-all-1.7.6.jar:1.7.6]
> at UIPortlet.run(UIPortlet.gtmpl:96) at org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:99) [exo.portal.component.scripting-3.5.2.Final-redhat-4.jar:3.5.2.Final-redhat-4]
--
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
11 years, 4 months
[JBoss JIRA] (GTNPORTAL-3156) NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3156?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration updated GTNPORTAL-3156:
-----------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=984405
> NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()
> --------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3156
> URL: https://issues.jboss.org/browse/GTNPORTAL-3156
> Project: GateIn Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Common integration, WebUI
> Affects Versions: 3.5.3.Final
> Environment: RHEL 5.9 64bits, Oracle/Sun jdk 1.7.0
> Reporter: Regis Mazur
> Priority: Minor
> Fix For: 3.5.3.Final
>
>
> During rendering of portal page an NPE error occurred when the portlet uicomponent try to retrieve theme (UIPortlet.getSuitedTheme() method).
> It can sometimes be reproduced when there are concurrent navigation requests (click around on the nav menu without waiting for a response).
> After investigation, it seems that the uicomponent tree is broken in this case and UIPortalApplication (null in this case) cannot be retrieve via the getAncestorOfType(UIPortalApplication.class) method.
> If you look at the content of uicomponent tree (see the "Expected results" and "Actual results"), you will see that standard portal uicomponent(UIPageBody,UIPortal,UISiteBody,UIViewWS,UIWorkingWorkspace,UIPortalApplication) are not in the tree.
> We reproduced the case in dev environment when there are concurrent navigation requests (click around around the nav menu without waiting for a response).
> It seems to be a concurrency issue in the portal itself.
> For the moment we fix the NPE in the UIPortlet.gtmpl (By retrieving the UIPortalApplication from the RequestContext instead of parsing the full uicomponent tree) but we don't fix the root cause and the possible side effects.
> Version-Release number of selected component (if applicable):
> GateIn 3.5.2.Final-redhat-4
> How reproducible:
> Not always. Mostly while testing within customer test environment where deployed portlets model is more significant in term of size and complexity.
> Steps to Reproduce:
> Actually we tried but we can't reproduce it locally using JSF2.1 Quickstart portlet calling same portlet tree. This only happens when using "full" application which has a lot of other dependencies.
> 1.
> 2.
> 3.
> Actual results:
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : queries
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row1
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:33:10,614 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : activities
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row2
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:34:11,868 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) Looking for UIPortalApplication parent
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : news
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : null - id : row2
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:34:28,807 INFO [stdout] (http-localhost/127.0.0.1:8080-5) parent : pp_portal_Dashboard - id : 22572705
> Expected results:
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) Looking for UIPortalApplication parent
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : tasks
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : row1
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : pp_portal_Dashboard - id : pp_portal_Dashboard
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : pp_portal_Dashboard - id : 22572705
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIPageBody - id : UIPageBody
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : clearstream - id : UIPortal
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UISiteBody - id : UISiteBody
> 16:32:56,597 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : null - id : 17689309
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIComponentDecorator - id : UIViewWS
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIWorkingWorkspace - id : UIWorkingWorkspace
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent : UIPortalApplication - id : UIPortalApplication
> 16:32:56,598 INFO [stdout] (http-localhost/127.0.0.1:8080-3) parent found : UIPortalApplication - id : UIPortalApplication
> Additional info:
> We think this caused by uiPortal.getAncestorOfType(UIPortalApplication.class) from UIComponent class which can't get the parent.
> We've got an actual proposed solution which is to use Util.getUIPortalApplication() instead to get the same thing (getSkin).
> Here is below the code snippet used:
> -----------------------
> String theme = null;
>
> try{
> theme = uicomponent.getSuitedTheme(null);
> } catch (RuntimeException e) {
> Map<String, String> themeMap = uicomponent.stringToThemeMap(uicomponent.getTheme());
> if (themeMap.containsKey(uiPortalApp.getSkin())) {
> theme = themeMap.get(uiPortalApp.getSkin());
> }
> else theme= uicomponent.DEFAULT_THEME.split(":")[1];
> }
> ----------------------
> While doing some searches, we found out Exo people have also used similar approach (refer to URL link below).
> http://lists.jboss.org/pipermail/gatein-commits/2010-November/005095.html
> Within Server.log we've got:
> Caused by: java.lang.NullPointerException
> at org.exoplatform.portal.webui.application.UIPortlet.getSuitedTheme(UIPortlet.java:270) [exo.portal.webui.portal-3.5.2.Final-redhat-4.jar:3.5.2.Final-redhat-4]
> at sun.reflect.GeneratedMethodAccessor1549.invoke(Unknown Source) [:1.7.0_06]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_06]
> at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_06]
> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229) [groovy-all-1.7.6.jar:1.7.6]
> at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52) [groovy-all-1.7.6.jar:1.7.6]
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) [groovy-all-1.7.6.jar:1.7.6]
> at UIPortlet.run(UIPortlet.gtmpl:96) at org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:99) [exo.portal.component.scripting-3.5.2.Final-redhat-4.jar:3.5.2.Final-redhat-4]
--
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
11 years, 4 months
[JBoss JIRA] (GTNPORTAL-2829) Null Session in WCI for cross context logout
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-2829?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-2829:
----------------------------------------------------
Tomas Kyjovsky <tkyjovsk(a)redhat.com> made a comment on [bug 958888|https://bugzilla.redhat.com/show_bug.cgi?id=958888]
Verified with 6.1.0.ER01.1 and 6.1.0.ER04. (Setting ER01 as target milestone)
JPP 6.0.0.GA
16:21:21,526 INFO [stdout] (http-localhost/127.0.0.1:8080-2) byteman >>> *** INVALIDATE SESSION 4cb8wAMpmR9112O7qb6hmqgR, context: /portal
16:21:21,528 INFO [stdout] (http-localhost/127.0.0.1:8080-2) byteman >>> *** INVALIDATE SESSION 4cb8wAMpmR9112O7qb6hmqgR, context: /portal
16:21:21,529 INFO [stdout] (http-localhost/127.0.0.1:8080-2) byteman >>> *** EXPIRE SESSION 4cb8wAMpmR9112O7qb6hmqgR, context: /portal
16:21:21,530 INFO [stdout] (http-localhost/127.0.0.1:8080-2) byteman >>> *** EXPIRE SESSION 4cb8wAMpmR9112O7qb6hmqgR, context: /portal
JPP 6.1.0.ER01.1
16:30:32,992 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** INVALIDATE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /portal
16:30:32,994 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** INVALIDATE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /portal
16:30:32,995 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /portal
16:30:33,027 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /exoadmin
16:30:33,027 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /exoadmin
16:30:33,028 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /redirect-portlet
16:30:33,029 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /redirect-portlet
16:30:33,029 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /web
16:30:33,029 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION GZIRoTIYufHUcNYNE6p-WJJC, context: /web
JPP 6.1.0.ER04
16:25:42,261 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** INVALIDATE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /portal
16:25:42,262 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** INVALIDATE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /portal
16:25:42,263 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /portal
16:25:42,264 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /portal
16:25:42,294 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /exoadmin
16:25:42,294 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /exoadmin
16:25:42,295 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /redirect-portlet
16:25:42,295 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /redirect-portlet
16:25:42,295 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /web
16:25:42,295 INFO [stdout] (http-localhost/127.0.0.1:8080-4) byteman >>> *** EXPIRE SESSION kaz31wq8+xzeKDZV7l0w9rpr, context: /web
> Null Session in WCI for cross context logout
> --------------------------------------------
>
> Key: GTNPORTAL-2829
> URL: https://issues.jboss.org/browse/GTNPORTAL-2829
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Nick Scavelli
> Assignee: Marko Strukelj
> Fix For: 3.6.0.Beta02
>
>
> It seems as though cross context logout is broken due to change done to PortalLogoutLifecycle to invalidate the session before calling logout in wci. This results in wci having a null session; hence, not being able perform cross context logout.
--
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
11 years, 4 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 updated GTNPC-109:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=997033, https://bugzilla.redhat.com/show_bug.cgi?id=997036 (was: https://bugzilla.redhat.com/show_bug.cgi?id=997033)
> 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
11 years, 4 months