June 2014 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded English labels in Title and Field Name

by Tuyen Nguyen The (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3491?page=com.atlassian.jira.pl... ] Work on GTNPORTAL-3491 started by Tuyen Nguyen The. > [Gadget] Hard-coded English labels in Title and Field Name > ---------------------------------------------------------- > > Key: GTNPORTAL-3491 > URL: https://issues.jboss.org/browse/GTNPORTAL-3491 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Internationalization and Localization > Affects Versions: 3.5.10.Final, 3.7.1.Final > Reporter: H. Trang Vu > Assignee: Tuyen Nguyen The > Attachments: VI-Title-FieldName.png > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Steps to reproduce: > * Login as root > * Go to Application Registry, add *Services Management* gadget into a category > * Switch to Vietnamese > * Open Dashboard > * Add *Services Management* gadget > * The gadget title is always in English > * Click pencil icon to edit gadget setting > ** "Services URL" is always in English -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded English labels in Title and Field Name

by Tuyen Nguyen The (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3491?page=com.atlassian.jira.pl... ] Tuyen Nguyen The reassigned GTNPORTAL-3491: ------------------------------------------- Assignee: Tuyen Nguyen The > [Gadget] Hard-coded English labels in Title and Field Name > ---------------------------------------------------------- > > Key: GTNPORTAL-3491 > URL: https://issues.jboss.org/browse/GTNPORTAL-3491 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Internationalization and Localization > Affects Versions: 3.5.10.Final, 3.7.1.Final > Reporter: H. Trang Vu > Assignee: Tuyen Nguyen The > Attachments: VI-Title-FieldName.png > > Original Estimate: 4 hours > Remaining Estimate: 4 hours > > Steps to reproduce: > * Login as root > * Go to Application Registry, add *Services Management* gadget into a category > * Switch to Vietnamese > * Open Dashboard > * Add *Services Management* gadget > * The gadget title is always in English > * Click pencil icon to edit gadget setting > ** "Services URL" is always in English -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3500) testMemoryLeakWithMultiThread fails sometimes

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3500?page=com.atlassian.jira.pl... ] Trong Tran edited comment on GTNPORTAL-3500 at 6/5/14 5:04 AM: --------------------------------------------------------------- It's not easy to reproduce the issue actually. However, I have made some changes to get the problem occurred more frequently (attached test case) The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's acceptable. I think we could deactivate the usecase. if we consider this is a real case, we could create an issue in eXo Kernel instead. was (Author: trong.tran): It's not easy to reproduce the issue actually. However, I have made some changes to get the problem occurred more frequently (attached test case) The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's normal I think we could deactivate the usecase. if we consider this is a real case, we could create an issue in eXo Kernel instead. > testMemoryLeakWithMultiThread fails sometimes > --------------------------------------------- > > Key: GTNPORTAL-3500 > URL: https://issues.jboss.org/browse/GTNPORTAL-3500 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Trong Tran > Attachments: TestDownloadService.java > > Original Estimate: 1 day, 4 hours > Time Spent: 4 hours > Remaining Estimate: 1 day > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1103304 > org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace: > junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:48) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertTrue(Assert.java:27) > at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > The line where it fails is > assertTrue(cache.getCacheSize() <= 10); > Version-Release number of selected component (if applicable): > GateIn 3.8.x or 3.9.x > Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and desktop. > Steps to Reproduce: > Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests repeatedly until it fails. > Actual results: > Test fails > Expected results: > Not sure if the subject under the test is broken or the test itself. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3500) testMemoryLeakWithMultiThread fails sometimes

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3500?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3500: ---------------------------------- Attachment: TestDownloadService.java It's not easy to reproduce the issue actually. However, I have made some changes to get the problem occurred more frequently (attached test case) The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's normal I think we could deactivate the usecase. if we consider this is a real case, we could create an issue in eXo Kernel instead. > testMemoryLeakWithMultiThread fails sometimes > --------------------------------------------- > > Key: GTNPORTAL-3500 > URL: https://issues.jboss.org/browse/GTNPORTAL-3500 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Trong Tran > Attachments: TestDownloadService.java > > Original Estimate: 1 day, 4 hours > Time Spent: 4 hours > Remaining Estimate: 1 day > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1103304 > org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace: > junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:48) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertTrue(Assert.java:27) > at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > The line where it fails is > assertTrue(cache.getCacheSize() <= 10); > Version-Release number of selected component (if applicable): > GateIn 3.8.x or 3.9.x > Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and desktop. > Steps to Reproduce: > Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests repeatedly until it fails. > Actual results: > Test fails > Expected results: > Not sure if the subject under the test is broken or the test itself. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind Load Balancers get wrong endpoint URL

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3505: ---------------------------------------------------- Juraci Paixao Krohling <jcosta(a)redhat.com> changed the Status of [bug 1102733|https://bugzilla.redhat.com/show_bug.cgi?id=1102733] from ASSIGNED to MODIFIED > WSRP Producers behind Load Balancers get wrong endpoint URL > ----------------------------------------------------------- > > Key: GTNPORTAL-3505 > URL: https://issues.jboss.org/browse/GTNPORTAL-3505 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind Load Balancers get wrong endpoint URL

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated GTNPORTAL-3505: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1102733 > WSRP Producers behind Load Balancers get wrong endpoint URL > ----------------------------------------------------------- > > Key: GTNPORTAL-3505 > URL: https://issues.jboss.org/browse/GTNPORTAL-3505 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind Load Balancers get wrong endpoint URL

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.pl... ] Juraci Paixão Kröhling updated GTNPORTAL-3505: ---------------------------------------------- Description: When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733. (was: When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and 1102733.) > WSRP Producers behind Load Balancers get wrong endpoint URL > ----------------------------------------------------------- > > Key: GTNPORTAL-3505 > URL: https://issues.jboss.org/browse/GTNPORTAL-3505 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3500) testMemoryLeakWithMultiThread fails sometimes

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3500?focusedWorklogId=12431302&... ] Trong Tran logged work on GTNPORTAL-3500: ----------------------------------------- Author: Trong Tran Created on: 04/Jun/14 9:58 PM Start Date: 04/Jun/14 9:58 AM Worklog Time Spent: 4 hours Issue Time Tracking ------------------- Remaining Estimate: 1 day (was: 1 day, 4 hours) Time Spent: 4 hours Worklog Id: (was: 12431302) > testMemoryLeakWithMultiThread fails sometimes > --------------------------------------------- > > Key: GTNPORTAL-3500 > URL: https://issues.jboss.org/browse/GTNPORTAL-3500 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Trong Tran > Original Estimate: 1 day, 4 hours > Time Spent: 4 hours > Remaining Estimate: 1 day > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1103304 > org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace: > junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:48) > at junit.framework.Assert.assertTrue(Assert.java:20) > at junit.framework.Assert.assertTrue(Assert.java:27) > at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > ... > The line where it fails is > assertTrue(cache.getCacheSize() <= 10); > Version-Release number of selected component (if applicable): > GateIn 3.8.x or 3.9.x > Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and desktop. > Steps to Reproduce: > Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests repeatedly until it fails. > Actual results: > Test fails > Expected results: > Not sure if the subject under the test is broken or the test itself. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-376) Different Portlet preference for remote portlets added on the same page

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-376?page=com.atlassian.jira.plugi... ] Juraci Paixão Kröhling closed GTNWSRP-376. ------------------------------------------ Resolution: Done Merged: https://github.com/gatein/gatein-wsrp/commit/631f7f0dc913df28675e258cb075... > Different Portlet preference for remote portlets added on the same page > ----------------------------------------------------------------------- > > Key: GTNWSRP-376 > URL: https://issues.jboss.org/browse/GTNWSRP-376 > Project: GateIn WSRP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.11.Final > Environment: Tested with : > JBoss Portal Platform - 6.1.1 (GateIn Portal 3.6.5) and > GateIn-3.8.0.Beta01 > Reporter: Anurag Debnath > Assignee: Juraci Paixão Kröhling > Attachments: PortletPreferencesPortlet.war.zip > > > When two instances of the same remote portlet is added to the same page, changes made to the preferences of one portlet is picked up by the other portlet as well. > Ideally, portlets should get their own preference/s. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-376) Different Portlet preference for remote portlets added on the same page

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-376?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on GTNWSRP-376: ------------------------------------------------- Juraci Paixao Krohling <jcosta(a)redhat.com> changed the Status of [bug 1094772|https://bugzilla.redhat.com/show_bug.cgi?id=1094772] from ASSIGNED to MODIFIED > Different Portlet preference for remote portlets added on the same page > ----------------------------------------------------------------------- > > Key: GTNWSRP-376 > URL: https://issues.jboss.org/browse/GTNWSRP-376 > Project: GateIn WSRP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.11.Final > Environment: Tested with : > JBoss Portal Platform - 6.1.1 (GateIn Portal 3.6.5) and > GateIn-3.8.0.Beta01 > Reporter: Anurag Debnath > Assignee: Juraci Paixão Kröhling > Attachments: PortletPreferencesPortlet.war.zip > > > When two instances of the same remote portlet is added to the same page, changes made to the preferences of one portlet is picked up by the other portlet as well. > Ideally, portlets should get their own preference/s. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues June 2014