June 2014 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3507) Update test case from PLIDM-46 to gatein-portal code base

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3507?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3507: ---------------------------------- Fix Version/s: 3.5.11.Final 3.7.2.Final 3.9.0.Final > Update test case from PLIDM-46 to gatein-portal code base > --------------------------------------------------------- > > Key: GTNPORTAL-3507 > URL: https://issues.jboss.org/browse/GTNPORTAL-3507 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.5.10.Final > Reporter: Tran Trung Thanh > Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final > > > PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNWCM-39) Tag version 2.1.0

by Lucas Ponce (JIRA)

[ https://issues.jboss.org/browse/GTNWCM-39?page=com.atlassian.jira.plugin.... ] Lucas Ponce reassigned GTNWCM-39: --------------------------------- Assignee: Lucas Ponce > Tag version 2.1.0 > ----------------- > > Key: GTNWCM-39 > URL: https://issues.jboss.org/browse/GTNWCM-39 > Project: GateIn WCM > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Lucas Ponce > Assignee: Lucas Ponce > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNWCM-39) Tag version 2.1.0

by Lucas Ponce (JIRA)

Lucas Ponce created GTNWCM-39: --------------------------------- Summary: Tag version 2.1.0 Key: GTNWCM-39 URL: https://issues.jboss.org/browse/GTNWCM-39 Project: GateIn WCM Issue Type: Enhancement Security Level: Public (Everyone can see) Reporter: Lucas Ponce -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNWCM-38) Export / Import

by Lucas Ponce (JIRA)

[ https://issues.jboss.org/browse/GTNWCM-38?page=com.atlassian.jira.plugin.... ] Lucas Ponce resolved GTNWCM-38. ------------------------------- Fix Version/s: 2.x Resolution: Done > Export / Import > --------------- > > Key: GTNWCM-38 > URL: https://issues.jboss.org/browse/GTNWCM-38 > Project: GateIn WCM > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 2.x > > > Add a export / import tool that can handle content in a bundle. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3512) Don't swallow exception when happens on IDM API

by Boubaker Khanfir (JIRA)

Boubaker Khanfir created GTNPORTAL-3512: ------------------------------------------- Summary: Don't swallow exception when happens on IDM API Key: GTNPORTAL-3512 URL: https://issues.jboss.org/browse/GTNPORTAL-3512 Project: GateIn Portal Issue Type: Enhancement Security Level: Public (Everyone can see) Affects Versions: 3.8.2.Final, 3.7.1.Final, 3.6.3.Final, 3.5.10.Final Reporter: Boubaker Khanfir The GateIN IDM implementation is a Data Management Layer Impl. Thus, the exceptions and errors occurred in this level have to be thrown to upper layer. In fact, if we see what is done in "recoverFromIDMError", we see that no exception is thrown after "rollback" operation is done. Let's take a simple example for this use case: I have an API that : # create a user. # create a group. # assign the user to this group. # do some other initialization tasks for that user. If, for example, I got an error in User creation operation, I will not be able to "break" the complete operation. As workaround, I have to do the "findUserByName", but this is not normal, because if the "saveUser" operation fails, it should throw an exception so that I can handle it. The modification in GateIN source code is simple: just add a "throw exception" at the end of "recoverFromIDMError" method. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher doesn't support IPv6 addresses

by Lucas Ponce (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3511?page=com.atlassian.jira.pl... ] Lucas Ponce updated GTNPORTAL-3511: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/gatein/gatein-shindig/pull/7 > BasicHttpFetcher doesn't support IPv6 addresses > ----------------------------------------------- > > Key: GTNPORTAL-3511 > URL: https://issues.jboss.org/browse/GTNPORTAL-3511 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shindig > Affects Versions: 3.8.2.Final > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.9.0.Final > > > BasicHttpFetcher.java cannot process IPv6 with format [::1]. > Some logic like this: > String[] hostparts = StringUtils.splitPreserveAllTokens(uri.getAuthority(),':'); > int port = -1; // default port > if (hostparts.length > 2) { > throw new GadgetException(GadgetException.Code.INVALID_USER_DATA, > "Bad host name in request: " + uri.getAuthority(), > HttpServletResponse.SC_BAD_REQUEST); > } > has to be updated to support IPv4 and IPv6 formats. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3510) Possible memory leaks, consistency issues and concurrency issues in ScriptGraph

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3510?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3510: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/gatein/gatein-portal/pull/879 > Possible memory leaks, consistency issues and concurrency issues in ScriptGraph > ------------------------------------------------------------------------------- > > Key: GTNPORTAL-3510 > URL: https://issues.jboss.org/browse/GTNPORTAL-3510 > Project: GateIn Portal > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Peter Palaga > > h4. Problems in the Present State > (1) Consitency: there are {{IllegalStateException}} s thrown when adding resources from a deployment. Those exceptions can be thrown in the middle of such an adding which can lead to an inconsistent state when resources from a particular deployment are partly there and partly not there in the {{ScriptGraph}}. > (2) Consitency: The present resource removal code does not ensure that a removed resource is also removed from dependent resources, closures and load groups. There are also no tests checking that. > (3) Possible leaks: closures and load groups are not cleaned upon resource removals which can lead to memory leaks. This is a consequence of (2). > (4) Concurrency: add and remove operations manipulate directly with collection instances that can be read (e.g. via {{getResource()}}) concurrently from other threads. > h4. Solution proposal > \(i) Make {{ScriptGraph}} immutable and always create a new instance (using some kind of builder pattern) when adding or removing resources. This should solve problems (1) and (4). > (ii) Improve the resource removal code to the effect that dependencies, closures and load groups are kept consistent upon removals. Add tests. This should solve problems (2) and (3). -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNMOP-54) Tests in WorkspaceTestCase are order dependent

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNMOP-54?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on GTNMOP-54: ----------------------------------------------- vramik(a)redhat.com changed the Status of [bug 1091114|https://bugzilla.redhat.com/show_bug.cgi?id=1091114] from ON_QA to VERIFIED > Tests in WorkspaceTestCase are order dependent > ---------------------------------------------- > > Key: GTNMOP-54 > URL: https://issues.jboss.org/browse/GTNMOP-54 > Project: GateIn Model Object for Portal > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1091114 > Description of problem: > Community MOP Core project (https://github.com/gatein/gatein-mop/tree/1.3.1.Final/core) has test dependency junit-4.10.jar (managed from gatein-dep-1.4.0.Final). > Prod MOP Core (http://git.app.eng.bos.redhat.com/git/gatein/gatein-mop.git/tree/core?id=...) has test dependency junit-4.11-redhat-1.jar. > There are junit 4.11 release notes: https://github.com/junit-team/junit/blob/master/doc/ReleaseNotes4.11.md#t... > Test execution order has changed between junit 4.10 and 4.11. I get test failures in org.gatein.mop.core.api.workspace.WorkspaceTestCase. It depends on order of execution of org.gatein.mop.core.api.workspace.WorkspaceTestCase.testRemoveReferencedTemplate. When the test is runned, all following tests, where a site "portal" is added (.addSite(ObjectType.PORTAL_SITE, "portal")), fails. In junit 4.10 the test is runned in the end of the test file so the tests passed but in 4.11 5 tests fails with ERROR org.chromattic.core.DomainSession - Attempt to insert context EntityContext[state=ObjectStatus[status=TRANSIENT],mapper=EntityMapper[class=class org.gatein.mop.core.api.workspace.PortalSite,typeName=mop:portalsite]] as an existing child with name mop:portal child of node /mop:workspace/mop:portalsites > Version-Release number of selected component (if applicable): > community MOP: 1.3.1.Final with junit 4.10 > prod MOP: 1.3.1.Final-redhat-1 with junit 4.11-redhat-1 > Additional info: > When I declare junit version to 4.11 in community project I get the errors. > When I declare junit version to 4.10-redhat-2 in prod project all tests passed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3506) Allow multiple apps registering the very same AMD paths

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3506?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3506: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/gatein/gatein-portal/pull/878 > Allow multiple apps registering the very same AMD paths > ------------------------------------------------------- > > Key: GTNPORTAL-3506 > URL: https://issues.jboss.org/browse/GTNPORTAL-3506 > Project: GateIn Portal > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Peter Palaga > > h4. Current state > GTNPORTAL-3502 introduced a common deployer for JavaScript and skin services with the following characteristics: when an app attempts to add an AMD path mapping that is available in the portal already, > all JS and CSS resources from that app are rejected. The path mapping comparison is done on path prefixes only, the target paths are not inspected at all. > Example: > * Application {{app.war}} wants to register the AMD module ID prefix > {{/dojo}} to be mapped to target path {{http://fastcdn.com/dojo/1.7.0}} > * But the prefix {{/dojo}} was registered already for > {{http://othercdn.com/dojo/1.9.1}} by some other application. > * All JS and CSS resources from {{app.war}} are rejected by skin and JSConfig services. > h4. Proposed change > The above approach is unnecessarily restrictive, because it rejects also applications that want to register the very same target path for a given prefix as is registered in the portal already. > Example: > * Application {{app2.war}} wants to register the AMD module ID prefix > {{/dojo}} to be mapped to target path {{http://fastcdn.com/dojo/1.7.0}} > * The prefix {{/dojo}} was previously registered by some other application {{app1.war}} to point to the very same target path {{http://fastcdn.com/dojo/1.7.0}}. > * JS and CSS resources from {{app2.war}} should be accepted by the portal because no inconsistency is introduced by {{app2.war}}. > * However, having accepted two or more apps relying on one path mapping, the portal must reject all changes that could break any of the affected applications. E.g. the portal may not remove the mapping on {{app1.war}} undeploy or it may not allow for re-deploying {{app1.war}} with a modified path mapping while {{app2.war}} is still active. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher doesn't support IPv6 addresses

by Lucas Ponce (JIRA)

Lucas Ponce created GTNPORTAL-3511: -------------------------------------- Summary: BasicHttpFetcher doesn't support IPv6 addresses Key: GTNPORTAL-3511 URL: https://issues.jboss.org/browse/GTNPORTAL-3511 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Shindig Affects Versions: 3.8.2.Final Reporter: Lucas Ponce Assignee: Lucas Ponce Fix For: 3.9.0.Final BasicHttpFetcher.java cannot process IPv6 with format [::1]. Some logic like this: String[] hostparts = StringUtils.splitPreserveAllTokens(uri.getAuthority(),':'); int port = -1; // default port if (hostparts.length > 2) { throw new GadgetException(GadgetException.Code.INVALID_USER_DATA, "Bad host name in request: " + uri.getAuthority(), HttpServletResponse.SC_BAD_REQUEST); } has to be updated to support IPv4 and IPv6 formats. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 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