June 2014 - gatein-issues - Jboss List Archives

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3506?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated GTNPORTAL-3506: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1110406 > 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 > Fix For: 3.8.3.Final, 3.9.0.Final > > > 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.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: Resolved (was: Pull Request Sent) Fix Version/s: 3.8.3.Final 3.9.0.Final Resolution: Done > 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 > Fix For: 3.8.3.Final, 3.9.0.Final > > > 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.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3509) [Application Registry] Missing validator when importing applications

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3509?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3509: ---------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1107566|https://bugzilla.redhat.com/show_bug.cgi?id=1107566] from POST to MODIFIED > [Application Registry] Missing validator when importing applications > -------------------------------------------------------------------- > > Key: GTNPORTAL-3509 > URL: https://issues.jboss.org/browse/GTNPORTAL-3509 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 3.5.10.Final, 3.7.1.Final, 3.8.2.Final > Reporter: H. Trang Vu > Assignee: Lucas Ponce > Priority: Minor > Fix For: 3.8.3.Final, 3.9.0.Final > > Attachments: SiteRedirectsAndImportExportAdminPortlet-TooLongAppName-DisplayName.png > > > When applications are added by configuration or by importing automatically all applications, there isn't any check of application name while its value is read-only after the creation. These validators (length and pattern) however existent when adding or editing an application. As a consequence, some imported applications cannot be changed (Display Name, Description, Access Permission). > Steps to reproduce: > # Login as root > # Go to Application Registry > # Click *Site Redirects and Import/Export* (the last item of *Administration* category). > # Change nothing. Click Save. Warning message appears as follows. > {noformat} > The length of the text in field "Application Name" must be between "3" and "30" characters. > The length of the text in field "Display Name" must be between "3" and "30" characters. > {noformat} > * It is feasible to reduce "Display Name" but not "Application Name" at run time. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3509) [Application Registry] Missing validator when importing applications

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3509?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3509: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.8.3.Final 3.9.0.Final Resolution: Done > [Application Registry] Missing validator when importing applications > -------------------------------------------------------------------- > > Key: GTNPORTAL-3509 > URL: https://issues.jboss.org/browse/GTNPORTAL-3509 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 3.5.10.Final, 3.7.1.Final, 3.8.2.Final > Reporter: H. Trang Vu > Assignee: Lucas Ponce > Priority: Minor > Fix For: 3.8.3.Final, 3.9.0.Final > > Attachments: SiteRedirectsAndImportExportAdminPortlet-TooLongAppName-DisplayName.png > > > When applications are added by configuration or by importing automatically all applications, there isn't any check of application name while its value is read-only after the creation. These validators (length and pattern) however existent when adding or editing an application. As a consequence, some imported applications cannot be changed (Display Name, Description, Access Permission). > Steps to reproduce: > # Login as root > # Go to Application Registry > # Click *Site Redirects and Import/Export* (the last item of *Administration* category). > # Change nothing. Click Save. Warning message appears as follows. > {noformat} > The length of the text in field "Application Name" must be between "3" and "30" characters. > The length of the text in field "Display Name" must be between "3" and "30" characters. > {noformat} > * It is feasible to reduce "Display Name" but not "Application Name" at run time. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3494) Names of imported applications in Application Registry are not localized

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3494?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3494: ---------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1107566|https://bugzilla.redhat.com/show_bug.cgi?id=1107566] from POST to MODIFIED > Names of imported applications in Application Registry are not localized > ------------------------------------------------------------------------- > > Key: GTNPORTAL-3494 > URL: https://issues.jboss.org/browse/GTNPORTAL-3494 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WebUI > Affects Versions: 3.8.1.Final > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.3.Final, 3.9.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3494) Names of imported applications in Application Registry are not localized

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3494?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3494: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Names of imported applications in Application Registry are not localized > ------------------------------------------------------------------------- > > Key: GTNPORTAL-3494 > URL: https://issues.jboss.org/browse/GTNPORTAL-3494 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WebUI > Affects Versions: 3.8.1.Final > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.3.Final, 3.9.0.Final > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 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: ---------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1102733|https://bugzilla.redhat.com/show_bug.cgi?id=1102733] from ON_QA 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 > Fix For: 3.8.3.Final, 3.9.0.Final > > > 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.6#6264)

10 years, 5 months

1
0
0 / 0

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

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3505: ------------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 3.8.3.Final 3.9.0.Final Resolution: Done > 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 > Fix For: 3.8.3.Final, 3.9.0.Final > > > 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.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3493) Membership just added, disappears

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3493?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3493: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Membership just added, disappears > --------------------------------- > > Key: GTNPORTAL-3493 > URL: https://issues.jboss.org/browse/GTNPORTAL-3493 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Boubaker Khanfir > Assignee: Marek Posolda > Fix For: 3.8.3.Final, 3.9.0.Final > > Attachments: plidm-ldap-membership-disappear.zip > > > I attach a new unit test for a bug that we met in GateIN 3.5 (PL IDM 1.4.4). > This one shows how we can add a membership and just after that it disappears. > In this file [idm-configuration.xml|https://github.com/gatein/gatein-portal/blob/3.5.x/...], the comment : > {quote} >  > {quote} > is not good and have to be like this: > {quote} >  > {quote} > What changes in this comment ? > The LDAP RW or ReadOnly have to get the same behavior using this parameter and we should map all LDAP groups in "ignoreMappedMembershipTypeGroupList". > I think it's better to force/compute this parameter in OrganizationService instead of giving the ability to do it manually. The other solution is to modify OrganizationService Impl to deal with such a use case but I prefer the first choice. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3495) Membership Pagination don't work

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3495?page=com.atlassian.jira.pl... ] Peter Palaga updated GTNPORTAL-3495: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Membership Pagination don't work > -------------------------------- > > Key: GTNPORTAL-3495 > URL: https://issues.jboss.org/browse/GTNPORTAL-3495 > Project: GateIn Portal > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 3.5.9.Final > Reporter: Boubaker Khanfir > Assignee: Marek Posolda > Fix For: 3.8.3.Final, 3.9.0.Final > > Attachments: plidm-ldap-membership-pagination.zip > > > I attach a new unit test for a bug that I met in PL IDM 1.4.4. > Test case description: > 1/ add about 10 users in an LDAP group > 2/ use SearchCriteria to paginate on the Members of this group > => Problem: pagination doesn't work > Why does it fails: > Because in this method "org.picketlink.idm.impl.store.ldap.LDAPIdentityStoreImpl.resolveRelationships(IdentityStoreInvocationContext, IdentityObject, IdentityObjectRelationshipType, boolean, boolean, String, IdentityObjectSearchCriteria)" the attribute "IdentityObjectSearchCriteria" isn't used for pagination. > To workaround this bug I had to use (skipPaginationInMembershipQuery=true). If the UI is buggy without this parameter to "true", I think it has to be *by default "true" in Config class* and may be even delete this option to not use pagination in Membership at all. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

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