August 2013 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3241) 508 type (o) skip navigation fix

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3241?page=com.atlassian.jira.pl... ] Peter Palaga resolved GTNPORTAL-3241. ------------------------------------- Fix Version/s: 3.6.3.Final Resolution: Done > 508 type (o) skip navigation fix > -------------------------------- > > Key: GTNPORTAL-3241 > URL: https://issues.jboss.org/browse/GTNPORTAL-3241 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Matt Wringe > Assignee: Matt Wringe > Fix For: 3.6.3.Final > > > Certain browsers (namely IE and possibly JAWS) don't give proper focus when clicking on an anchor. In these cases, the page will scroll to the anchor but the focus will remain on the content just before the anchor link. > In firefox and chrome, anchor work properly and as expected. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3232) CNFE when WSS activated and accessing a wsrp portlet

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3232?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3232: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.6.3.Final Resolution: Done > CNFE when WSS activated and accessing a wsrp portlet > ---------------------------------------------------- > > Key: GTNPORTAL-3232 > URL: https://issues.jboss.org/browse/GTNPORTAL-3232 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Matt Wringe > Fix For: 3.6.3.Final > > > When accessing a page with a remote portlet, when ws-security is enabled, results in a ClassNotFoundException for the callbackhandler. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3239) GateIn Redirect Admin UI: Alert shows <undefined><undefined> if shown when previous is fading

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3239?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3239: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.6.3.Final Resolution: Done > GateIn Redirect Admin UI: Alert shows <undefined><undefined> if shown when previous is fading > --------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3239 > URL: https://issues.jboss.org/browse/GTNPORTAL-3239 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 3.6.1.Final > Reporter: Alexandre Mendonça > Assignee: Alexandre Mendonça > Fix For: 3.6.3.Final > > > If two actions which show alert notification (eg: delete and save redirect) are done in such short time so that the 2nd alert comes in when the 1st is fading out, the alert is show as "<undefined> <undefined>" and in yellow (default) color. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3242) Redirect name is displayed in two lines on Chrome

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3242?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3242: ---------------------------------------------------- Viliam Rockai <vrockai(a)redhat.com> changed the Status of [bug 996137|https://bugzilla.redhat.com/show_bug.cgi?id=996137] from ASSIGNED to MODIFIED > Redirect name is displayed in two lines on Chrome > ------------------------------------------------- > > Key: GTNPORTAL-3242 > URL: https://issues.jboss.org/browse/GTNPORTAL-3242 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 3.6.1.Final > Environment: Fedora 17 + Chrome > Reporter: Viliam Rockai > Assignee: Viliam Rockai > > This bug is affecting only Fedora on Chrome. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3237) GateIn Redirect Admin UI: Node mapping shows nodes for origin when selecting redirect nodes

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3237?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3237: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.6.3.Final Resolution: Done > GateIn Redirect Admin UI: Node mapping shows nodes for origin when selecting redirect nodes > ------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3237 > URL: https://issues.jboss.org/browse/GTNPORTAL-3237 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 3.6.1.Final > Reporter: Alexandre Mendonça > Assignee: Alexandre Mendonça > Fix For: 3.6.3.Final > > > When creating Classic redirect, both Origin and Redirect Node Mapping lists contain classic nodes. When creating Mobile redirect - both lists are mobile. > Actual results: > Redirect Node Mapping list displays classic nodes > Expected results: > Redirect Node Mapping list should display mobile nodes when creating redirection to Mobile site -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3182) Portal 'overriding' maximization of a window in case multiple portlets on the page receive any event but only one of them changes the portlet window mode

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3182?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3182: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.6.3.Final Resolution: Done > Portal 'overriding' maximization of a window in case multiple portlets on the page receive any event but only one of them changes the portlet window mode > --------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3182 > URL: https://issues.jboss.org/browse/GTNPORTAL-3182 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WebUI > Affects Versions: 3.5.0.Final > Environment: GateIn portal 3.5.0 > Reporter: Adam Kovari > Fix For: 3.6.3.Final > > Attachments: 00905214-src.zip, case_00903245_using_code_for_case_00905214.ppt, portal_classic_2013-07-19_14-34-18.zip, portletstates-testcase.zip > > > 1- During the action phase a portlet of the layout (producer) raises an event that contains both the target portlet reference (portlet ID) and the target window state desired. > 2- The consumer portlets of the event (note: all portlet in the page may not consume the raised event but only a subset of them will) check if they are the target portlet of the event. In such a case they change the WindowState to the target state. > 3- What we observe is that mechanism works if we have: > - only one consumer on the page > - the consumer is in the last position of the consumer portlets. > > Cases where we have multiple consumer on the page and where the target consumer is not the last in the event consumer list changes the WindowState accoding to command but the rendering of the portlet does not correspond to the correct state. Typically when we desire to maximize the portlet the actual WindowState of all portlets are OK (1 portlet is maximized and others are normal) but the render phase of all portlets are evaluated which is not the case when you perform a maximize using the WindowState button on the UI or when the portlet is in the position last from the portlets recieving the event. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3156) NullPointerException when rendering portlet in method UIPortlet.getSuitedTheme()

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3156?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3156: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3238) WSRP doesn't properly pick up configuration files from documented configuration directory

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3238?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3238: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.6.3.Final (was: 3.6.2.Final) Resolution: Done > WSRP doesn't properly pick up configuration files from documented configuration directory > ----------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3238 > URL: https://issues.jboss.org/browse/GTNPORTAL-3238 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WSRP integration > Affects Versions: 3.6.1.Final > Reporter: Chris Laprun > Priority: Minor > Fix For: 3.6.3.Final > > > Configuration directory for WSRP has been changed and needs to be updated in configuration files. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3242) Redirect name is displayed in two lines on Chrome

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3242?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3242: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Redirect name is displayed in two lines on Chrome > ------------------------------------------------- > > Key: GTNPORTAL-3242 > URL: https://issues.jboss.org/browse/GTNPORTAL-3242 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: User Interface > Affects Versions: 3.6.1.Final > Environment: Fedora 17 + Chrome > Reporter: Viliam Rockai > Assignee: Viliam Rockai > > This bug is affecting only Fedora on Chrome. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3243) Exceptions are swallowed in PicketLinkIDMOrganizationServiceImpl flush and endRequest

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3243?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated GTNPORTAL-3243: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=998885 > Exceptions are swallowed in PicketLinkIDMOrganizationServiceImpl flush and endRequest > ------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3243 > URL: https://issues.jboss.org/browse/GTNPORTAL-3243 > Project: GateIn Portal > Issue Type: Bug > Components: Identity integration > Affects Versions: 3.6.0.Final > Reporter: Martin Weiler > Assignee: Marek Posolda > > IDM operations are invoked from a WS facade in our environment, and not from the GUI. Therefore, we have overridden PicketLinkIDMOrganizationServiceImpl.recoverFromIDMError to just let any errors bubble up and let the upper layer handle it, instead of rolling back + restarting the transaction. > But here's the place the exception handling is not working as expected. The issue is in PicketLinkIDMOrganizationServiceImpl.flush(): > {code} > public void flush() { > try { > if (configuration.isUseJTA()) { > if (traceLoggingEnabled) { > log.trace("Flushing UserTransaction in method flush"); > } > // Complete restart of JTA transaction don't have good performance. So we will only sync identitySession (same > // as for non-jta environment) > // finishJTATransaction(); > // beginJTATransaction(); > if (jtaTransactionLifecycleService.getUserTransaction().getStatus() == Status.STATUS_ACTIVE) { > idmService_.getIdentitySession().save(); > } > } else { > try { > if (idmService_.getIdentitySession().getTransaction().isActive()) { > 166: idmService_.getIdentitySession().save(); > } > } catch (Exception e) { > log.error(e.getMessage(), e); > 170: recoverFromIDMError(e); > } > } > 174: } catch (Exception e) { > 175: log.error(e.getMessage(), e); > } > } > {code} > Let's assume there is an exception at session.save() in line 166. This exception is then handled by the recoverFromIDMError method in line 170. In our environment, this method is overridden and throws an Exception. > But the initial goal of overriding this method, which was to have this exception propagated to the caller, is not reached here, as there is an outer try..catch block in the PicketLinkIDMOrganizationServiceImpl.flush() method which just logs the error. > The outer try..catch block should be removed in flush() and endRequest(). -- 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, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues August 2013