May 2014 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for JavaScript and skin services

by Peter Palaga (JIRA)

Peter Palaga created GTNPORTAL-3502: --------------------------------------- Summary: Commnon deployer for JavaScript and skin services Key: GTNPORTAL-3502 URL: https://issues.jboss.org/browse/GTNPORTAL-3502 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Peter Palaga Assignee: Peter Palaga At present, there are two independent deployers for JavaScript and skin services: {{GateInSkinConfigDeployer}} and {{JavascriptConfigDeployer}}. There are two problems with that: (1) Both of them parse {{gatein-resources.xml}} independently, which is a performance drawback. (2) They can succeed or fail independently, e.g. in case there is some meaningless declaration in {{gatein-resources.xml}}, which can lead to an inconsistent state of the portal. An ideal solution for (2) would be to rollback deployment of the whole web application, but unfortunately, the present design of the portal does not allow for that. Therefore, I propose to keep at least the two services consistent by introducing a common deployer, that will grant that resources will either succeed to be added to both or to none. Problem (1) will be solved by that too. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema validation for gatein-resources.xml

by Peter Palaga (JIRA)

Peter Palaga created GTNPORTAL-3501: --------------------------------------- Summary: Introduce XML schema validation for gatein-resources.xml Key: GTNPORTAL-3501 URL: https://issues.jboss.org/browse/GTNPORTAL-3501 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Peter Palaga Assignee: Peter Palaga There are several lines of code that indicate that {{org.exoplatform.commons.xml.XMLValidator}} was originally designed to check if a given document complies with an XML schema declared in it: {code:java} factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaSource", schemas); factory.setNamespaceAware(true); factory.setValidating(true); {code} However, there were no tests checking if the validation works and indeed, it does not. It is out of the present scope to investigate what is wrong with {{XMLValidator}} and how it can be corrected, because it is too general to be used for validating {{gatein-resources.xml}} at this point. The main problem is that if we have not validated so far, there must be a lot of schema-incompatible {{gatein-resources.xml}} out there in the wild that were silently accepted by the portal in the past. Therefore, we cannot start validating all {{gatein-resources.xml}} files now. To meet the natural expectation that inputs are properly validated to widest possible extent, I propose to start validating now, but only {{gatein-resources.xml}} documents that use the namespace {{http://www.gatein.org/xml/ns/gatein_resources_1_5}} or newer. {{gatein_resources_1_5.xsd}} will be introduced these days with fixing GTNPORTAL-3485 and GTNPORTAL-3487. In this way we can stay backwards-compatible and start validating from now on. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

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

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3500?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3500: ------------------------------------ Description: 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. was: 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): JBoss Portal 6.2.0.ER2 How 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. Actual results: Test fails Expected results: Not sure if the subject under the test is broken or the test itself. > 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 > > 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, 7 months

1
0
0 / 0

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

by Peter Palaga (JIRA)

Peter Palaga created GTNPORTAL-3500: --------------------------------------- Summary: 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 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): JBoss Portal 6.2.0.ER2 How 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. 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, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3457) Unify gatein jgroups configurations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3457?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3457: ---------------------------------------------------- Tomas Kyjovsky <tkyjovsk(a)redhat.com> changed the Status of [bug 1090675|https://bugzilla.redhat.com/show_bug.cgi?id=1090675] from ON_QA to VERIFIED > Unify gatein jgroups configurations > ----------------------------------- > > Key: GTNPORTAL-3457 > URL: https://issues.jboss.org/browse/GTNPORTAL-3457 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.0.Final > > > GateIn cluster configuration is defined under: > ./gatein/gatein.ear/portal.war/WEB-INF/classes/jgroups/ folder. > There are two separate jgroups configurations for exo.jcr and idm subsystems that can be merged into one. > Also, some properties has to be reviewed, as binding ips and enable_diagnostics. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3457) Unify gatein jgroups configurations

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3457?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3457: ---------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1090675|https://bugzilla.redhat.com/show_bug.cgi?id=1090675] from POST to ON_QA > Unify gatein jgroups configurations > ----------------------------------- > > Key: GTNPORTAL-3457 > URL: https://issues.jboss.org/browse/GTNPORTAL-3457 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.0.Final > > > GateIn cluster configuration is defined under: > ./gatein/gatein.ear/portal.war/WEB-INF/classes/jgroups/ folder. > There are two separate jgroups configurations for exo.jcr and idm subsystems that can be merged into one. > Also, some properties has to be reviewed, as binding ips and enable_diagnostics. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3476) Obsolete version numbers in jboss packaging

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3476?page=com.atlassian.jira.pl... ] Work on GTNPORTAL-3476 stopped by Peter Palaga. > Obsolete version numbers in jboss packaging > ------------------------------------------- > > Key: GTNPORTAL-3476 > URL: https://issues.jboss.org/browse/GTNPORTAL-3476 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.8.0.Final > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.9.0.Final > > > The versions in jboss packaging are still on 3.8.0.Beta02-SNAPSHOT, see https://github.com/gatein/gatein-portal/blob/3.8.0.Final/packaging/jboss/... > It is probably, because packaging/jboss is not included by default and I released 3.8.0.Final without the new dedicated profile. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3476) Obsolete version numbers in jboss packaging

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3476?page=com.atlassian.jira.pl... ] Work on GTNPORTAL-3476 started by Peter Palaga. > Obsolete version numbers in jboss packaging > ------------------------------------------- > > Key: GTNPORTAL-3476 > URL: https://issues.jboss.org/browse/GTNPORTAL-3476 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.8.0.Final > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.9.0.Final > > > The versions in jboss packaging are still on 3.8.0.Beta02-SNAPSHOT, see https://github.com/gatein/gatein-portal/blob/3.8.0.Final/packaging/jboss/... > It is probably, because packaging/jboss is not included by default and I released 3.8.0.Final without the new dedicated profile. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3476) Obsolete version numbers in jboss packaging

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3476?page=com.atlassian.jira.pl... ] Peter Palaga resolved GTNPORTAL-3476. ------------------------------------- Fix Version/s: 3.9.0.Final Resolution: Done Fixed by https://github.com/gatein/gatein-portal/commit/8970fd4eadd6752fdd3969f19c... > Obsolete version numbers in jboss packaging > ------------------------------------------- > > Key: GTNPORTAL-3476 > URL: https://issues.jboss.org/browse/GTNPORTAL-3476 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.8.0.Final > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.9.0.Final > > > The versions in jboss packaging are still on 3.8.0.Beta02-SNAPSHOT, see https://github.com/gatein/gatein-portal/blob/3.8.0.Final/packaging/jboss/... > It is probably, because packaging/jboss is not included by default and I released 3.8.0.Final without the new dedicated profile. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3396) Support all possible js module dependency names in define()

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3396?page=com.atlassian.jira.pl... ] Peter Palaga resolved GTNPORTAL-3396. ------------------------------------- Fix Version/s: 3.8.0.Final Resolution: Done Fixed by https://github.com/gatein/gatein-portal/commit/1554d8b0b6855527334eb72337... > Support all possible js module dependency names in define() > ----------------------------------------------------------- > > Key: GTNPORTAL-3396 > URL: https://issues.jboss.org/browse/GTNPORTAL-3396 > Project: GateIn Portal > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 3.7.0.Final > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.8.0.Final > > > Let's have a dependeny graph as simple as: > dojo/sniff depends on dojo/has > Given that both dojo/sniff and dojo/has live in the same directory named "dojo", the dojo/sniff.js file starts with > define(["./has"], function(has){ > Note the relative module path name "./has" there. Relative paths comply with the AMD spec [1] and "../<someModule>" should also be supported. > Using such relative module names in define() does not seem to work in GateIn. > [1] https://github.com/amdjs/amdjs-api/wiki/AMD -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues May 2014