March 2015 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3578) Dependency org.apache.commons.io is not present in org.apache.commons.fileupload module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3578?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3578: ---------------------------------------------------- Tomas Kyjovsky <tkyjovsk(a)redhat.com> 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)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3578) Dependency org.apache.commons.io is not present in org.apache.commons.fileupload module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3578?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3578: ---------------------------------------------------- Tomas Kyjovsky <tkyjovsk(a)redhat.com> 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)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3579) Add validation for surrogate pair of characters on UITabbedDashboard

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3579?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3579: ---------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> 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)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot decode surrogate pair characters

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNCOMMON-24?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on GTNCOMMON-24: -------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> 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)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3569) Reduce the performance impact of the cache of the TemplateService in a cluster

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3569?page=com.atlassian.jira.pl... ] 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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3569) Reduce the performance impact of the cache of the TemplateService in a cluster

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3569?page=com.atlassian.jira.pl... ] 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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3582) Scroll buttons of UIPortalNavigation doesn't work properly

by Vu Viet Phuong (JIRA)

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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3524: ---------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> 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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.pl... ] 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)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3581) IDM Pool become full due to hibernate session leak

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3581?page=com.atlassian.jira.pl... ] 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<RequestContext> 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)

9 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues March 2015