From issues at jboss.org Mon Mar 2 08:37:49 2015 From: issues at jboss.org (Neji Gammoudi (JIRA)) Date: Mon, 2 Mar 2015 08:37:49 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3580) Make the PicketLinkIDMService hot deployed with new configuration In-Reply-To: References: Message-ID: Neji Gammoudi created GTNPORTAL-3580: ---------------------------------------- Summary: Make the PicketLinkIDMService hot deployed with new configuration Key: GTNPORTAL-3580 URL: https://issues.jboss.org/browse/GTNPORTAL-3580 Project: GateIn Portal Issue Type: Feature Request Components: Identity integration Affects Versions: 3.5.10.Final Reporter: Neji Gammoudi Assignee: Boleslaw Dawidowicz I want to make an administration LDAP screen for eXoPlatform from which i can update the LDAP configuration for different implementations (openldap,opends,ad,...) that requires the load of different XML configuration files such as picketlink-idm-msad-config.xml and picketlink-idm-ldap-config.xml ,... I didn't found any way to make the PciketLinkIDMService hot deployed with new configuration. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 2 08:54:50 2015 From: issues at jboss.org (Neji Gammoudi (JIRA)) Date: Mon, 2 Mar 2015 08:54:50 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3580) Make the PicketLinkIDMService hot deployed with new configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045222#comment-13045222 ] Neji Gammoudi commented on GTNPORTAL-3580: ------------------------------------------ For now , i was able to hot deploy this service by implementing a new method under [PicketLinkIDMServiceImpl|https://github.com/gatein/gatein-portal/blob/master/component/identity/src/main/java/org/exoplatform/services/organization/idm/PicketLinkIDMServiceImpl.java] which loads all objects in the constructor with the new value of config property. > Make the PicketLinkIDMService hot deployed with new configuration > ----------------------------------------------------------------- > > Key: GTNPORTAL-3580 > URL: https://issues.jboss.org/browse/GTNPORTAL-3580 > Project: GateIn Portal > Issue Type: Feature Request > Components: Identity integration > Affects Versions: 3.5.10.Final > Reporter: Neji Gammoudi > Assignee: Boleslaw Dawidowicz > > I want to make an administration LDAP screen for eXoPlatform from which i can update the LDAP configuration for different implementations (openldap,opends,ad,...) that requires the load of different XML configuration files such as picketlink-idm-msad-config.xml and picketlink-idm-ldap-config.xml ,... > I didn't found any way to make the PciketLinkIDMService hot deployed with new configuration. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 05:16:49 2015 From: issues at jboss.org (Trong Tran (JIRA)) Date: Tue, 3 Mar 2015 05:16:49 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3581) IDM Pool become full due to hibernate session leak In-Reply-To: References: Message-ID: Trong Tran created GTNPORTAL-3581: ------------------------------------- Summary: IDM Pool become full due to hibernate session leak Key: GTNPORTAL-3581 URL: https://issues.jboss.org/browse/GTNPORTAL-3581 Project: GateIn Portal Issue Type: Bug Reporter: Trong Tran Assignee: Trong Tran Fix For: 3.9.0.Final All ApplicationLifecycle starts should be always ended to prevent idm session leak. We noticed in some cases that The ApplicationLifeCycle isn't closed : {code:java}try { for (ApplicationLifecycle lifecycle : getApplicationLifecycle()) { lifecycle.onStartRequest(this, context); } ... ..... } finally { WebuiRequestContext.setCurrentInstance(parentAppRequestContext); }{code} This case appears In /webui/portlet/src/main/java/org/exoplatform/webui/application/portlet/PortletApplication.java in these methods : - serveResource(ResourceRequest req, ResourceResponse res) - processEvent(EventRequest req, EventResponse res) - processAction(ActionRequest req, ActionResponse res) *PS* : In the comment of the method serverResource(), it's already mentioned that "onEndRequest()" call should be invoqued in the finally block. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 05:21:49 2015 From: issues at jboss.org (Trong Tran (JIRA)) Date: Tue, 3 Mar 2015 05:21:49 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3581) IDM Pool become full due to hibernate session leak In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trong Tran resolved GTNPORTAL-3581. ----------------------------------- Resolution: Done > IDM Pool become full due to hibernate session leak > -------------------------------------------------- > > Key: GTNPORTAL-3581 > URL: https://issues.jboss.org/browse/GTNPORTAL-3581 > Project: GateIn Portal > Issue Type: Bug > Reporter: Trong Tran > Assignee: Trong Tran > Fix For: 3.9.0.Final > > > All ApplicationLifecycle starts should be always ended to prevent idm session leak. > We noticed in some cases that The ApplicationLifeCycle isn't closed : > {code:java}try { > for (ApplicationLifecycle lifecycle : getApplicationLifecycle()) { > lifecycle.onStartRequest(this, context); > } > ... > ..... > } finally { > WebuiRequestContext.setCurrentInstance(parentAppRequestContext); > }{code} > This case appears In /webui/portlet/src/main/java/org/exoplatform/webui/application/portlet/PortletApplication.java in these methods : > - serveResource(ResourceRequest req, ResourceResponse res) > - processEvent(EventRequest req, EventResponse res) > - processAction(ActionRequest req, ActionResponse res) > *PS* : In the comment of the method serverResource(), it's already mentioned that "onEndRequest()" call should be invoqued in the finally block. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 08:29:49 2015 From: issues at jboss.org (Peter Palaga (JIRA)) Date: Tue, 3 Mar 2015 08:29:49 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Palaga updated GTNPORTAL-3524: ------------------------------------ Fix Version/s: 3.8.14.Final > Custom portals cannot use remote portlets > ----------------------------------------- > > Key: GTNPORTAL-3524 > URL: https://issues.jboss.org/browse/GTNPORTAL-3524 > Project: GateIn Portal > Issue Type: Bug > Components: WSRP integration > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.9.0.Final, 3.8.14.Final > > > Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. > This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . > With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. > With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. > While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 08:30:50 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 3 Mar 2015 08:30:50 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045631#comment-13045631 ] RH Bugzilla Integration commented on GTNPORTAL-3524: ---------------------------------------------------- Peter Palaga changed the Status of [bug 1122527|https://bugzilla.redhat.com/show_bug.cgi?id=1122527] from POST to MODIFIED > Custom portals cannot use remote portlets > ----------------------------------------- > > Key: GTNPORTAL-3524 > URL: https://issues.jboss.org/browse/GTNPORTAL-3524 > Project: GateIn Portal > Issue Type: Bug > Components: WSRP integration > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.9.0.Final, 3.8.14.Final > > > Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. > This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . > With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. > With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. > While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 3 21:51:48 2015 From: issues at jboss.org (Vu Viet Phuong (JIRA)) Date: Tue, 3 Mar 2015 21:51:48 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3582) Scroll buttons of UIPortalNavigation doesn't work properly In-Reply-To: References: Message-ID: Vu Viet Phuong created GTNPORTAL-3582: ----------------------------------------- Summary: Scroll buttons of UIPortalNavigation doesn't work properly Key: GTNPORTAL-3582 URL: https://issues.jboss.org/browse/GTNPORTAL-3582 Project: GateIn Portal Issue Type: Bug Components: WebUI Affects Versions: 3.8.2.Final Reporter: Vu Viet Phuong Priority: Minor Step to reproduce: - No easy way to reproduce it in gatein. We must write a resizable popup window and put the UIPortalNavigation component inside it. Or a fast way to test is that: we can use browser tool (firebug...) to change the width of UIPortalNavigation - Add some navigation nodes, resize the UIPortalNavigation util it show the scroll buttons - Click the right button -- it's works as expected, now resize the UIPortalNavigation to maximum --> even if there are enough spaces, the hidden nodes are not shown, and the scroll buttons is node hide --> expected: after click to right button, then resize to have enough space, all the nodes are show and the scrollbutton is hide -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 02:59:50 2015 From: issues at jboss.org (Trong Tran (JIRA)) Date: Wed, 4 Mar 2015 02:59:50 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3569) Reduce the performance impact of the cache of the TemplateService in a cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Trong Tran updated GTNPORTAL-3569: ---------------------------------- Fix Version/s: 3.9.0.Final > Reduce the performance impact of the cache of the TemplateService in a cluster > ------------------------------------------------------------------------------ > > Key: GTNPORTAL-3569 > URL: https://issues.jboss.org/browse/GTNPORTAL-3569 > Project: GateIn Portal > Issue Type: Enhancement > Components: Performance > Affects Versions: 3.8.8.Final > Reporter: Nicolas Filotto > Fix For: 3.9.0.Final > > > While trying to identify the root cause of the performances regression between JPP 6.1.1 and JPP 6.2, I realized that the bug fix for https://issues.jboss.org/browse/GTNPORTAL-3410 is actually buggy and causes a significant performance regression. > It is buggy because as the variable script of the class GroovyTemplate is transient, its value is not replicated over the cluster so far so good, the problem is that there is no synchronization mechanism to ensure that the value of this variable will be created only once even if we have several concurrent threads that try to access to its value, this is a real issue especially when we know that building the value of this particular variable has a significant cost. > It causes a significant performance regression because it replaces an eXo Cache based on a ConcurrentHashMap with an eXo Cache based on ISPN in replicated mode, according to my micro benchmarks, the get method of a ConcurrentHashMap is 11 times faster than the get method of ISPN so when we know that the cache of the TemplateService is very frequently used we know that this configuration change will have a significant impact on performances -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 4 03:50:49 2015 From: issues at jboss.org (Trong Tran (JIRA)) Date: Wed, 4 Mar 2015 03:50:49 -0500 (EST) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3569) Reduce the performance impact of the cache of the TemplateService in a cluster In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13046051#comment-13046051 ] Trong Tran commented on GTNPORTAL-3569: --------------------------------------- Thank [~nfilotto] for your investigation. It makes sense to use eXo Cache based on a ConcurrentHashMap, until the performance issue with ISPN is fixed. [~bdaw] could you take a look and see if you have any input about this ? > Reduce the performance impact of the cache of the TemplateService in a cluster > ------------------------------------------------------------------------------ > > Key: GTNPORTAL-3569 > URL: https://issues.jboss.org/browse/GTNPORTAL-3569 > Project: GateIn Portal > Issue Type: Enhancement > Components: Performance > Affects Versions: 3.8.8.Final > Reporter: Nicolas Filotto > Fix For: 3.9.0.Final > > > While trying to identify the root cause of the performances regression between JPP 6.1.1 and JPP 6.2, I realized that the bug fix for https://issues.jboss.org/browse/GTNPORTAL-3410 is actually buggy and causes a significant performance regression. > It is buggy because as the variable script of the class GroovyTemplate is transient, its value is not replicated over the cluster so far so good, the problem is that there is no synchronization mechanism to ensure that the value of this variable will be created only once even if we have several concurrent threads that try to access to its value, this is a real issue especially when we know that building the value of this particular variable has a significant cost. > It causes a significant performance regression because it replaces an eXo Cache based on a ConcurrentHashMap with an eXo Cache based on ISPN in replicated mode, according to my micro benchmarks, the get method of a ConcurrentHashMap is 11 times faster than the get method of ISPN so when we know that the cache of the TemplateService is very frequently used we know that this configuration change will have a significant impact on performances -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 09:22:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 13 Mar 2015 09:22:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot decode surrogate pair characters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNCOMMON-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049854#comment-13049854 ] RH Bugzilla Integration commented on GTNCOMMON-24: -------------------------------------------------- Honza Fnukal changed the Status of [bug 1105521|https://bugzilla.redhat.com/show_bug.cgi?id=1105521] from MODIFIED to ON_QA > FastURLDecoder cannot decode surrogate pair characters > ------------------------------------------------------ > > Key: GTNCOMMON-24 > URL: https://issues.jboss.org/browse/GTNCOMMON-24 > Project: GateIn Common > Issue Type: Bug > Reporter: Takayuki Konishi > Attachments: surrogatepairtest.patch > > > FastURLDecoder cannot decode surrogate pair characters. > When I decoded [U+20000B|http://www.fileformat.info/info/unicode/char/2000B/index.htm], I got MalformedInputException: > {code} > org.gatein.common.text.MalformedInputException: Cannot decode char 'A0' > at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217) > at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45) > at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62) > at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159) > {code} > I also attach a patch for testcase. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 09:22:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 13 Mar 2015 09:22:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3579) Add validation for surrogate pair of characters on UITabbedDashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049855#comment-13049855 ] RH Bugzilla Integration commented on GTNPORTAL-3579: ---------------------------------------------------- Honza Fnukal changed the Status of [bug 1105521|https://bugzilla.redhat.com/show_bug.cgi?id=1105521] from MODIFIED to ON_QA > Add validation for surrogate pair of characters on UITabbedDashboard > -------------------------------------------------------------------- > > Key: GTNPORTAL-3579 > URL: https://issues.jboss.org/browse/GTNPORTAL-3579 > Project: GateIn Portal > Issue Type: Bug > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.14.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 12:57:18 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 13 Mar 2015 12:57:18 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3578) Dependency org.apache.commons.io is not present in org.apache.commons.fileupload module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049994#comment-13049994 ] RH Bugzilla Integration commented on GTNPORTAL-3578: ---------------------------------------------------- Tomas Kyjovsky changed the Status of [bug 1133873|https://bugzilla.redhat.com/show_bug.cgi?id=1133873] from MODIFIED to ON_QA > Dependency org.apache.commons.io is not present in org.apache.commons.fileupload module > --------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3578 > URL: https://issues.jboss.org/browse/GTNPORTAL-3578 > Project: GateIn Portal > Issue Type: Bug > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.9.0.Final, 3.8.14.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 12:58:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 13 Mar 2015 12:58:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3578) Dependency org.apache.commons.io is not present in org.apache.commons.fileupload module In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049995#comment-13049995 ] RH Bugzilla Integration commented on GTNPORTAL-3578: ---------------------------------------------------- Tomas Kyjovsky changed the Status of [bug 1133873|https://bugzilla.redhat.com/show_bug.cgi?id=1133873] from ON_QA to ASSIGNED > Dependency org.apache.commons.io is not present in org.apache.commons.fileupload module > --------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3578 > URL: https://issues.jboss.org/browse/GTNPORTAL-3578 > Project: GateIn Portal > Issue Type: Bug > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.9.0.Final, 3.8.14.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Fri Mar 13 13:00:18 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Fri, 13 Mar 2015 13:00:18 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13049997#comment-13049997 ] RH Bugzilla Integration commented on GTNPORTAL-3524: ---------------------------------------------------- Tomas Kyjovsky changed the Status of [bug 1122527|https://bugzilla.redhat.com/show_bug.cgi?id=1122527] from MODIFIED to ON_QA > Custom portals cannot use remote portlets > ----------------------------------------- > > Key: GTNPORTAL-3524 > URL: https://issues.jboss.org/browse/GTNPORTAL-3524 > Project: GateIn Portal > Issue Type: Bug > Components: WSRP integration > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.9.0.Final, 3.8.14.Final > > > Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. > This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . > With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. > With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. > While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 08:26:19 2015 From: issues at jboss.org (Peter Palaga (JIRA)) Date: Mon, 16 Mar 2015 08:26:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3577) Remove mentions to LinkedIn OAuth in for JBoss-based packaging In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050429#comment-13050429 ] Peter Palaga commented on GTNPORTAL-3577: ----------------------------------------- There is one more commit to fix this: https://github.com/gatein/gatein-portal/commit/499defa92ca0df4a877c05f4d8f38bcaf248294f > Remove mentions to LinkedIn OAuth in for JBoss-based packaging > -------------------------------------------------------------- > > Key: GTNPORTAL-3577 > URL: https://issues.jboss.org/browse/GTNPORTAL-3577 > Project: GateIn Portal > Issue Type: Bug > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.8.14.Final > > > The LinkedIn OAuth integration currently misses a few pieces to work on JBoss AS and related (Wildfly, EAP, ...). So, the configuration file needs to be changed to remove mentions to it, until this integration is done and tested for this package. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 10:10:19 2015 From: issues at jboss.org (Neji Gammoudi (JIRA)) Date: Mon, 16 Mar 2015 10:10:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3580) Make the PicketLinkIDMService hot deployed with new configuration In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050511#comment-13050511 ] Neji Gammoudi commented on GTNPORTAL-3580: ------------------------------------------ Hello, Any news about this issue Please? > Make the PicketLinkIDMService hot deployed with new configuration > ----------------------------------------------------------------- > > Key: GTNPORTAL-3580 > URL: https://issues.jboss.org/browse/GTNPORTAL-3580 > Project: GateIn Portal > Issue Type: Feature Request > Components: Identity integration > Affects Versions: 3.5.10.Final > Reporter: Neji Gammoudi > Assignee: Boleslaw Dawidowicz > > I want to make an administration LDAP screen for eXoPlatform from which i can update the LDAP configuration for different implementations (openldap,opends,ad,...) that requires the load of different XML configuration files such as picketlink-idm-msad-config.xml and picketlink-idm-ldap-config.xml ,... > I didn't found any way to make the PciketLinkIDMService hot deployed with new configuration. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Mon Mar 16 14:54:18 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Mon, 16 Mar 2015 14:54:18 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050643#comment-13050643 ] RH Bugzilla Integration commented on GTNPORTAL-3524: ---------------------------------------------------- Tomas Kyjovsky changed the Status of [bug 1122527|https://bugzilla.redhat.com/show_bug.cgi?id=1122527] from ON_QA to VERIFIED > Custom portals cannot use remote portlets > ----------------------------------------- > > Key: GTNPORTAL-3524 > URL: https://issues.jboss.org/browse/GTNPORTAL-3524 > Project: GateIn Portal > Issue Type: Bug > Components: WSRP integration > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.9.0.Final, 3.8.14.Final > > > Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. > This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . > With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. > With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. > While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 17 08:09:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 17 Mar 2015 08:09:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot decode surrogate pair characters In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNCOMMON-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050888#comment-13050888 ] RH Bugzilla Integration commented on GTNCOMMON-24: -------------------------------------------------- Tomas Kyjovsky changed the Status of [bug 1105521|https://bugzilla.redhat.com/show_bug.cgi?id=1105521] from ON_QA to VERIFIED > FastURLDecoder cannot decode surrogate pair characters > ------------------------------------------------------ > > Key: GTNCOMMON-24 > URL: https://issues.jboss.org/browse/GTNCOMMON-24 > Project: GateIn Common > Issue Type: Bug > Reporter: Takayuki Konishi > Attachments: surrogatepairtest.patch > > > FastURLDecoder cannot decode surrogate pair characters. > When I decoded [U+20000B|http://www.fileformat.info/info/unicode/char/2000B/index.htm], I got MalformedInputException: > {code} > org.gatein.common.text.MalformedInputException: Cannot decode char 'A0' > at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217) > at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45) > at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62) > at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159) > {code} > I also attach a patch for testcase. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 17 08:09:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 17 Mar 2015 08:09:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3579) Add validation for surrogate pair of characters on UITabbedDashboard In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3579?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13050889#comment-13050889 ] RH Bugzilla Integration commented on GTNPORTAL-3579: ---------------------------------------------------- Tomas Kyjovsky changed the Status of [bug 1105521|https://bugzilla.redhat.com/show_bug.cgi?id=1105521] from ON_QA to VERIFIED > Add validation for surrogate pair of characters on UITabbedDashboard > -------------------------------------------------------------------- > > Key: GTNPORTAL-3579 > URL: https://issues.jboss.org/browse/GTNPORTAL-3579 > Project: GateIn Portal > Issue Type: Bug > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.14.Final > > -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 17 10:40:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 17 Mar 2015 10:40:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3560) Cache-control on the UI encodes too much In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051016#comment-13051016 ] RH Bugzilla Integration commented on GTNPORTAL-3560: ---------------------------------------------------- Peter Palaga changed the Status of [bug 1165102|https://bugzilla.redhat.com/show_bug.cgi?id=1165102] from MODIFIED to ON_QA > Cache-control on the UI encodes too much > ---------------------------------------- > > Key: GTNPORTAL-3560 > URL: https://issues.jboss.org/browse/GTNPORTAL-3560 > Project: GateIn Portal > Issue Type: Feature Request > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.9.0.Final, 3.8.9.Alpha02 > > > The cache-control directive, when specified on the UI, gets too much encoding when being set as a header. This means that it's not useful at the current state when more than one parameter for the cache-control is set: > For instance, the string "no-cache, max-age=0, must-revalidate, no-store" becomes this header: > {code}Cache-Control:no-cache%2C+max-age%3D0%2C+must-revalidate%2C+no-store{code} > The input should be sanitized only for new lines, to avoid a "HTTP Response Splitting" attack. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Tue Mar 17 10:48:20 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Tue, 17 Mar 2015 10:48:20 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3572) Missing exception handling in MembeshipDAOImpl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051030#comment-13051030 ] RH Bugzilla Integration commented on GTNPORTAL-3572: ---------------------------------------------------- Peter Palaga changed the Status of [bug 1179940|https://bugzilla.redhat.com/show_bug.cgi?id=1179940] from MODIFIED to ON_QA > Missing exception handling in MembeshipDAOImpl > ---------------------------------------------- > > Key: GTNPORTAL-3572 > URL: https://issues.jboss.org/browse/GTNPORTAL-3572 > Project: GateIn Portal > Issue Type: Bug > Components: Identity integration > Affects Versions: 3.8.2.Final > Reporter: Martin Weiler > Assignee: Boleslaw Dawidowicz > Fix For: 3.9.0.Final, 3.8.14.Final > > > MembershipDAOImpl.linkMembership(...) is missing exception handling around the following call: > {code} > getIdentitySession().getRoleManager().createRole(mt.getName(), user.getUserName(), groupId); > {code} > If this call fails, eg. for example due to an exception from the underlying database, this result in a corrupted transaction state. Subsequent requests using this thread fail with an error similar to the following: > {noformat} > org.hibernate.AssertionFailure: null id in org.picketlink.idm.impl.model.hibernate.HibernateIdentityObjectRelationship entry (don't flush the Session after an exception occurs) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 06:37:18 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Mar 2015 06:37:18 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3560) Cache-control on the UI encodes too much In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051280#comment-13051280 ] RH Bugzilla Integration commented on GTNPORTAL-3560: ---------------------------------------------------- vramik at redhat.com changed the Status of [bug 1165102|https://bugzilla.redhat.com/show_bug.cgi?id=1165102] from ON_QA to VERIFIED > Cache-control on the UI encodes too much > ---------------------------------------- > > Key: GTNPORTAL-3560 > URL: https://issues.jboss.org/browse/GTNPORTAL-3560 > Project: GateIn Portal > Issue Type: Feature Request > Reporter: Juraci Paix?o Kr?hling > Assignee: Juraci Paix?o Kr?hling > Fix For: 3.9.0.Final, 3.8.9.Alpha02 > > > The cache-control directive, when specified on the UI, gets too much encoding when being set as a header. This means that it's not useful at the current state when more than one parameter for the cache-control is set: > For instance, the string "no-cache, max-age=0, must-revalidate, no-store" becomes this header: > {code}Cache-Control:no-cache%2C+max-age%3D0%2C+must-revalidate%2C+no-store{code} > The input should be sanitized only for new lines, to avoid a "HTTP Response Splitting" attack. -- This message was sent by Atlassian JIRA (v6.3.11#6341) From issues at jboss.org Wed Mar 18 12:27:19 2015 From: issues at jboss.org (RH Bugzilla Integration (JIRA)) Date: Wed, 18 Mar 2015 12:27:19 -0400 (EDT) Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3572) Missing exception handling in MembeshipDAOImpl In-Reply-To: References: Message-ID: [ https://issues.jboss.org/browse/GTNPORTAL-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13051478#comment-13051478 ] RH Bugzilla Integration commented on GTNPORTAL-3572: ---------------------------------------------------- vramik at redhat.com changed the Status of [bug 1179940|https://bugzilla.redhat.com/show_bug.cgi?id=1179940] from ON_QA to VERIFIED > Missing exception handling in MembeshipDAOImpl > ---------------------------------------------- > > Key: GTNPORTAL-3572 > URL: https://issues.jboss.org/browse/GTNPORTAL-3572 > Project: GateIn Portal > Issue Type: Bug > Components: Identity integration > Affects Versions: 3.8.2.Final > Reporter: Martin Weiler > Assignee: Boleslaw Dawidowicz > Fix For: 3.9.0.Final, 3.8.14.Final > > > MembershipDAOImpl.linkMembership(...) is missing exception handling around the following call: > {code} > getIdentitySession().getRoleManager().createRole(mt.getName(), user.getUserName(), groupId); > {code} > If this call fails, eg. for example due to an exception from the underlying database, this result in a corrupted transaction state. Subsequent requests using this thread fail with an error similar to the following: > {noformat} > org.hibernate.AssertionFailure: null id in org.picketlink.idm.impl.model.hibernate.HibernateIdentityObjectRelationship entry (don't flush the Session after an exception occurs) > {noformat} -- This message was sent by Atlassian JIRA (v6.3.11#6341)