From issues at jboss.org  Tue Jul  1 09:36:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3513) Layout of portlet is
 broken in preview mode using extensions
In-Reply-To: <JIRA.12544134.1403008296000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544134.1403008296000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544134.1403008296000.32883.1404221785363@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981019#comment-12981019 ] 

RH Bugzilla Integration commented on GTNPORTAL-3513:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1102754|https://bugzilla.redhat.com/show_bug.cgi?id=1102754] from MODIFIED to ON_QA

> Layout of portlet is broken in preview mode using extensions
> ------------------------------------------------------------
>
>                 Key: GTNPORTAL-3513
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3513
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> Using extensions that add a new Skin can make portlets using Default skin loose style in UIPortalComposer.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Tue Jul  1 09:36:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3503) Define a default
 order for page management results
In-Reply-To: <JIRA.12542616.1401787347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542616.1401787347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542616.1401787347000.32885.1404221785585@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981020#comment-12981020 ] 

RH Bugzilla Integration commented on GTNPORTAL-3503:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1102742|https://bugzilla.redhat.com/show_bug.cgi?id=1102742] from MODIFIED to ON_QA

> Define a default order for page management results
> --------------------------------------------------
>
>                 Key: GTNPORTAL-3503
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3503
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> POMSession.findObjects() performs a pages query without a default order.
> This can cause an issue in PageManagement portlet repeating results.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Tue Jul  1 09:36:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3363) Provide feedback on
 logs when gadget is not white-listed
In-Reply-To: <JIRA.12529126.1389373623000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529126.1389373623000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529126.1389373623000.32888.1404221785894@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981022#comment-12981022 ] 

RH Bugzilla Integration commented on GTNPORTAL-3363:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 794468|https://bugzilla.redhat.com/show_bug.cgi?id=794468] from MODIFIED to ON_QA

> Provide feedback on logs when gadget is not white-listed
> --------------------------------------------------------
>
>                 Key: GTNPORTAL-3363
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3363
>             Project: GateIn Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>             Fix For: 3.7.0.Final
>
>
> When a gadget is not white-listed, the ProxyFilterService rejects the loading of the contents, but provides no hints on the logs about it, making the user to believe that the gadget might be at fault. A solution is to log at INFO level that access to it has been blocked. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Tue Jul  1 09:36:27 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3509) [Application
 Registry] Missing validator when importing applications
In-Reply-To: <JIRA.12543220.1402300153000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543220.1402300153000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543220.1402300153000.32901.1404221787046@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981025#comment-12981025 ] 

RH Bugzilla Integration commented on GTNPORTAL-3509:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1107566|https://bugzilla.redhat.com/show_bug.cgi?id=1107566] from MODIFIED to ON_QA

> [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)

From issues at jboss.org  Tue Jul  1 09:36:27 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3494) Names of imported
 applications in Application Registry are not localized
In-Reply-To: <JIRA.12541900.1401118291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541900.1401118291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541900.1401118291000.32903.1404221787223@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981024#comment-12981024 ] 

RH Bugzilla Integration commented on GTNPORTAL-3494:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1107566|https://bugzilla.redhat.com/show_bug.cgi?id=1107566] from MODIFIED to ON_QA

> 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)

From issues at jboss.org  Tue Jul  1 09:36:27 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3500)
 testMemoryLeakWithMultiThread fails sometimes
In-Reply-To: <JIRA.12542430.1401469023000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542430.1401469023000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542430.1401469023000.32906.1404221787406@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981026#comment-12981026 ] 

RH Bugzilla Integration commented on GTNPORTAL-3500:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1103304|https://bugzilla.redhat.com/show_bug.cgi?id=1103304] from MODIFIED to ON_QA

> 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
>             Fix For: 3.9.0.Final
>
>         Attachments: TestDownloadService.java
>
>   Original Estimate: 1 day, 4 hours
>          Time Spent: 1 day
>  Remaining Estimate: 0 minutes
>
> 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.6#6264)

From issues at jboss.org  Tue Jul  1 09:36:27 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3506) Allow multiple apps
 registering the very same AMD paths
In-Reply-To: <JIRA.12542915.1401967625000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542915.1401967625000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542915.1401967625000.32908.1404221787520@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981028#comment-12981028 ] 

RH Bugzilla Integration commented on GTNPORTAL-3506:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1110406|https://bugzilla.redhat.com/show_bug.cgi?id=1110406] from MODIFIED to ON_QA

> 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)

From issues at jboss.org  Tue Jul  1 09:36:27 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind
 Load Balancers get wrong endpoint URL
In-Reply-To: <JIRA.12542783.1401892628000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542783.1401892628000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542783.1401892628000.32911.1404221787697@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981029#comment-12981029 ] 

RH Bugzilla Integration commented on GTNPORTAL-3505:
----------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1102733|https://bugzilla.redhat.com/show_bug.cgi?id=1102733] from MODIFIED to ON_QA

> 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)


From issues at jboss.org  Tue Jul  1 09:36:27 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 1 Jul 2014 09:36:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-376) Different Portlet
 preference for remote portlets added on the same page
In-Reply-To: <JIRA.12539955.1399380095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12539955.1399380095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539955.1399380095000.32914.1404221787938@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNWSRP-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981030#comment-12981030 ] 

RH Bugzilla Integration commented on GTNWSRP-376:
-------------------------------------------------

Honza Fnukal <hfnukal at redhat.com> changed the Status of [bug 1094772|https://bugzilla.redhat.com/show_bug.cgi?id=1094772] from MODIFIED to ON_QA

> 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.6#6264)


From issues at jboss.org  Wed Jul  2 01:43:24 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 2 Jul 2014 01:43:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3517) Cannot start Gatein
 Portal with MySQL in UTF-8
In-Reply-To: <JIRA.12545292.1404279719071@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545292.1404279719071@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545292.1404279719071.34419.1404279804015@jira02.app.mwc.hst.phx2.redhat.com>

Tran Trung Thanh created GTNPORTAL-3517:
-------------------------------------------

             Summary: Cannot start Gatein Portal with MySQL in UTF-8
                 Key: GTNPORTAL-3517
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3517
             Project: GateIn Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Tran Trung Thanh


If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
{code}
Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	... 81 common frames omitted
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
{code}

NB: The db schema has been created using the next command:
{code}
CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
{code}

To make Gatein Portal work with MySQL in UTF-8, we need to [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  2 01:43:24 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 2 Jul 2014 01:43:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3517) Cannot start Gatein
 Portal with MySQL in UTF-8
In-Reply-To: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545292.1404279719000.34420.1404279804072@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tran Trung Thanh updated GTNPORTAL-3517:
----------------------------------------

    Affects Version/s: 3.5.10.Final


> Cannot start Gatein Portal with MySQL in UTF-8
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3517
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3517
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
> {code}
> Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	... 81 common frames omitted
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
> 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> {code}
> NB: The db schema has been created using the next command:
> {code}
> CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
> {code}
> To make Gatein Portal work with MySQL in UTF-8, we need to [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  2 03:31:24 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 2 Jul 2014 03:31:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3517) Cannot start Gatein
 Portal with MySQL in UTF-8
In-Reply-To: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545292.1404279719000.34515.1404286284328@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tran Trung Thanh updated GTNPORTAL-3517:
----------------------------------------

    Description: 
If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
{code}
Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	... 81 common frames omitted
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
{code}

NB: The db schema has been created using the next command:
{code}
CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
{code}

To make Gatein Portal work with MySQL in UTF-8, we need [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.

  was:
If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
{code}
Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	... 81 common frames omitted
Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
{code}

NB: The db schema has been created using the next command:
{code}
CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
{code}

To make Gatein Portal work with MySQL in UTF-8, we need to [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



> Cannot start Gatein Portal with MySQL in UTF-8
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3517
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3517
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
> {code}
> Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	... 81 common frames omitted
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
> 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> {code}
> NB: The db schema has been created using the next command:
> {code}
> CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
> {code}
> To make Gatein Portal work with MySQL in UTF-8, we need [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  2 03:41:24 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 2 Jul 2014 03:41:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3517) Cannot start Gatein
 Portal with MySQL in UTF-8
In-Reply-To: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545292.1404279719000.34537.1404286884602@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tran Trung Thanh updated GTNPORTAL-3517:
----------------------------------------

    Git Pull Request: https://github.com/gatein/gatein-portal/pull/884


> Cannot start Gatein Portal with MySQL in UTF-8
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3517
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3517
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
> {code}
> Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	... 81 common frames omitted
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
> 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> {code}
> NB: The db schema has been created using the next command:
> {code}
> CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
> {code}
> To make Gatein Portal work with MySQL in UTF-8, we need [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  2 03:41:24 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 2 Jul 2014 03:41:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3517) Cannot start Gatein
 Portal with MySQL in UTF-8
In-Reply-To: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545292.1404279719000.34540.1404286884988@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tran Trung Thanh updated GTNPORTAL-3517:
----------------------------------------

    Status: Pull Request Sent  (was: Open)


> Cannot start Gatein Portal with MySQL in UTF-8
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3517
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3517
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
> {code}
> Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	... 81 common frames omitted
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
> 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> {code}
> NB: The db schema has been created using the next command:
> {code}
> CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
> {code}
> To make Gatein Portal work with MySQL in UTF-8, we need [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  2 08:20:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Jul 2014 08:20:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3513) Layout of portlet is
 broken in preview mode using extensions
In-Reply-To: <JIRA.12544134.1403008296000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544134.1403008296000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544134.1403008296000.35256.1404303625351@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981371#comment-12981371 ] 

RH Bugzilla Integration commented on GTNPORTAL-3513:
----------------------------------------------------

Petr Mensik <pmensik at redhat.com> changed the Status of [bug 1102754|https://bugzilla.redhat.com/show_bug.cgi?id=1102754] from ON_QA to VERIFIED

> Layout of portlet is broken in preview mode using extensions
> ------------------------------------------------------------
>
>                 Key: GTNPORTAL-3513
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3513
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> Using extensions that add a new Skin can make portlets using Default skin loose style in UIPortalComposer.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  2 08:53:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Jul 2014 08:53:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3509) [Application
 Registry] Missing validator when importing applications
In-Reply-To: <JIRA.12543220.1402300153000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543220.1402300153000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543220.1402300153000.35381.1404305604821@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981389#comment-12981389 ] 

RH Bugzilla Integration commented on GTNPORTAL-3509:
----------------------------------------------------

Petr Mensik <pmensik at redhat.com> changed the Status of [bug 1107566|https://bugzilla.redhat.com/show_bug.cgi?id=1107566] from ON_QA to VERIFIED

> [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)

From issues at jboss.org  Wed Jul  2 08:53:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Jul 2014 08:53:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3494) Names of imported
 applications in Application Registry are not localized
In-Reply-To: <JIRA.12541900.1401118291000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541900.1401118291000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541900.1401118291000.35384.1404305605091@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981390#comment-12981390 ] 

RH Bugzilla Integration commented on GTNPORTAL-3494:
----------------------------------------------------

Petr Mensik <pmensik at redhat.com> changed the Status of [bug 1107566|https://bugzilla.redhat.com/show_bug.cgi?id=1107566] from ON_QA to VERIFIED

> 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)

From issues at jboss.org  Wed Jul  2 10:11:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Jul 2014 10:11:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind
 Load Balancers get wrong endpoint URL
In-Reply-To: <JIRA.12542783.1401892628000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542783.1401892628000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542783.1401892628000.35858.1404310284110@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981446#comment-12981446 ] 

RH Bugzilla Integration commented on GTNPORTAL-3505:
----------------------------------------------------

vramik at redhat.com changed the Status of [bug 1102733|https://bugzilla.redhat.com/show_bug.cgi?id=1102733] from ON_QA to VERIFIED

> 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)


From issues at jboss.org  Wed Jul  2 10:31:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 2 Jul 2014 10:31:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-376) Different Portlet
 preference for remote portlets added on the same page
In-Reply-To: <JIRA.12539955.1399380095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12539955.1399380095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539955.1399380095000.35930.1404311484826@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNWSRP-376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981462#comment-12981462 ] 

RH Bugzilla Integration commented on GTNWSRP-376:
-------------------------------------------------

vramik at redhat.com changed the Status of [bug 1094772|https://bugzilla.redhat.com/show_bug.cgi?id=1094772] from ON_QA to VERIFIED

> 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.6#6264)


From issues at jboss.org  Thu Jul  3 04:38:26 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Jul 2014 04:38:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-2801) Add eviction to
	indexer-config.xml
In-Reply-To: <JIRA.12482766.1358409580000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12482766.1358409580000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12482766.1358409580000.38653.1404376706432@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12981805#comment-12981805 ] 

RH Bugzilla Integration commented on GTNPORTAL-2801:
----------------------------------------------------

Lucas Ponce <lponce at redhat.com> changed the Status of [bug 1048695|https://bugzilla.redhat.com/show_bug.cgi?id=1048695] from ASSIGNED to CLOSED

> Add eviction to indexer-config.xml
> ----------------------------------
>
>                 Key: GTNPORTAL-2801
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-2801
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: JCR integration
>    Affects Versions: 3.5.0.Final
>            Reporter: Toshiya Kobayashi
>
> gatein.ear/portal.war/WEB-INF/conf/jcr/jbosscache/cluster/indexer-config.xml doesn't have eviction configuration. It may cause a memory leak in slave nodes.
> {code:xml}
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1">
>   <locking useLockStriping="false" concurrencyLevel="64" lockParentForChildInsertRemove="false"
>            lockAcquisitionTimeout="20000"/>
>   <!-- Configure the TransactionManager -->
>   <transaction transactionManagerLookupClass="org.jboss.cache.transaction.JBossStandaloneJTAManagerLookup"/>
>   <clustering mode="replication" clusterName="${jboss.partition.name:DefaultPartition}-${jbosscache-cluster-name}">
>     <stateRetrieval timeout="20000" fetchInMemoryState="false"/>
>     <jgroupsConfig configFile="jgroups/gatein-${gatein.default.jgroups.stack:udp}.xml"/>
>     <sync/>
>   </clustering>
> </jbosscache>
> {code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul  3 10:20:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 3 Jul 2014 10:20:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3363) Provide feedback on
 logs when gadget is not white-listed
In-Reply-To: <JIRA.12529126.1389373623000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529126.1389373623000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529126.1389373623000.40445.1404397225682@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982072#comment-12982072 ] 

RH Bugzilla Integration commented on GTNPORTAL-3363:
----------------------------------------------------

vramik at redhat.com changed the Status of [bug 794468|https://bugzilla.redhat.com/show_bug.cgi?id=794468] from ON_QA to VERIFIED

> Provide feedback on logs when gadget is not white-listed
> --------------------------------------------------------
>
>                 Key: GTNPORTAL-3363
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3363
>             Project: GateIn Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>             Fix For: 3.7.0.Final
>
>
> When a gadget is not white-listed, the ProxyFilterService rejects the loading of the contents, but provides no hints on the logs about it, making the user to believe that the gadget might be at fault. A solution is to log at INFO level that access to it has been blocked. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul  4 03:09:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Jul 2014 03:09:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3487) Add an option to load
	CSS from a CDN
In-Reply-To: <JIRA.12541386.1400680523000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541386.1400680523000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541386.1400680523000.41592.1404457764205@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated GTNPORTAL-3487:
-----------------------------------------------

    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1103765, https://bugzilla.redhat.com/show_bug.cgi?id=1116278  (was: https://bugzilla.redhat.com/show_bug.cgi?id=1103765)


> Add an option to load CSS from a CDN
> ------------------------------------
>
>                 Key: GTNPORTAL-3487
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3487
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> Loading CSS from an external URL is not possible ATM. This a task similar to GTNPORTAL-3485.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Fri Jul  4 04:15:31 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 4 Jul 2014 04:15:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3487) Add an option to load
	CSS from a CDN
In-Reply-To: <JIRA.12541386.1400680523000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541386.1400680523000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541386.1400680523000.41695.1404461731682@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982292#comment-12982292 ] 

RH Bugzilla Integration commented on GTNPORTAL-3487:
----------------------------------------------------

Aakanksha <aasingh at redhat.com> changed the Status of [bug 1116278|https://bugzilla.redhat.com/show_bug.cgi?id=1116278] from NEW to ASSIGNED

> Add an option to load CSS from a CDN
> ------------------------------------
>
>                 Key: GTNPORTAL-3487
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3487
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> Loading CSS from an external URL is not possible ATM. This a task similar to GTNPORTAL-3485.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Mon Jul  7 03:34:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Mon, 7 Jul 2014 03:34:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3515) Should refresh data
 in Membership management form without relogin
In-Reply-To: <JIRA.12544565.1403488633000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544565.1403488633000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544565.1403488633000.43476.1404718464443@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trong Tran updated GTNPORTAL-3515:
----------------------------------

    Fix Version/s: 3.5.11.Final
                   3.7.2.Final
                   3.9.0.Final


> Should refresh data in Membership management form without relogin
> -----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3515
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3515
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Tuyen Nguyen The
>            Priority: Minor
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>
> Use 2 browser to access to gatein:
> On browser 1
> + Access to gatein
> + Login with user root
> + Go to Users/Group and Roles/Membership management
> + Create new membership
> On browser 2:
> + Access to gatein
> + Login with user root
> + Go to Users/Group and Roles/Membership management -> see membership above => OK
> + Edit info of this membership
> On browser 1: Refresh Membership management form but do not see updated info of membership => NOK
> Go to browser 2: Delete this membership
> Go to browser 1:
> + Refresh Membership management form but still see this membership => NOK
> + Click Edit icon of this membership -> Unknown error (has exception)
> {code}
> [http-bio-8080-exec-1] ERROR portal:UIPortalApplication - Error during the processAction phase
> java.lang.NullPointerException
> 	at org.exoplatform.organization.webui.component.UIListMembershipType$EditMembershipActionListener.execute(UIListMembershipType.java:85)
> 	at org.exoplatform.webui.event.Event.broadcast(Event.java:97)
> 	at org.exoplatform.webui.core.lifecycle.Lifecycle.processAction(Lifecycle.java:51)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.lifecycle.UIApplicationLifecycle.processAction(UIApplicationLifecycle.java:53)
> 	at org.exoplatform.webui.core.lifecycle.UIApplicationLifecycle.processAction(UIApplicationLifecycle.java:30)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.UIApplication.processAction(UIApplication.java:123)
> 	at org.exoplatform.webui.application.portlet.PortletApplication.processAction(PortletApplication.java:152)
> 	at org.exoplatform.webui.application.portlet.PortletApplicationController.processAction(PortletApplicationController.java:88)
> 	at org.gatein.pc.portlet.impl.jsr168.PortletContainerImpl$Invoker.doFilter(PortletContainerImpl.java:581)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:109)
> 	at org.exoplatform.portal.application.ApplicationMonitoringFilter.doFilter(ApplicationMonitoringFilter.java:41)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:109)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:72)
> 	at org.gatein.pc.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:529)
> 	at org.gatein.pc.portlet.container.ContainerPortletDispatcher.invoke(ContainerPortletDispatcher.java:42)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.EventPayloadInterceptor.invoke(EventPayloadInterceptor.java:197)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.RequestAttributeConversationInterceptor.invoke(RequestAttributeConversationInterceptor.java:119)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.CCPPInterceptor.invoke(CCPPInterceptor.java:65)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor.access$201(ContextDispatcherInterceptor.java:46)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor$CallableImpl.call(ContextDispatcherInterceptor.java:119)
> 	at org.exoplatform.portal.webui.application.ExoServerContext$1.doCallback(ExoServerContext.java:49)
> 	at org.gatein.wci.command.CommandDispatcher$CallbackCommand.execute(CommandDispatcher.java:82)
> 	at org.gatein.wci.command.TomcatCommandDispatcher$1.execute(TomcatCommandDispatcher.java:61)
> 	at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.gatein.wci.command.CommandServlet.doGet(CommandServlet.java:135)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544)
> 	at org.gatein.wci.command.CommandServlet.include(CommandServlet.java:84)
> 	at org.gatein.wci.command.TomcatCommandDispatcher.include(TomcatCommandDispatcher.java:97)
> 	at org.gatein.wci.tomcat.TC7ServletContainerContext.include(TC7ServletContainerContext.java:113)
> 	at org.gatein.wci.ServletContainer.include(ServletContainer.java:395)
> 	at org.exoplatform.portal.webui.application.ExoServerContext.dispatch(ExoServerContext.java:45)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:65)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.exoplatform.portal.pc.aspects.PortletLifecyclePhaseInterceptor.invoke(PortletLifecyclePhaseInterceptor.java:30)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ValveInterceptor.invoke(ValveInterceptor.java:84)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.container.ContainerPortletInvoker.invoke(ContainerPortletInvoker.java:131)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:263)
> 	at org.gatein.pc.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:163)
> 	at org.gatein.pc.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:246)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.PortletCustomizationInterceptor.invoke(PortletCustomizationInterceptor.java:76)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:247)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.exoplatform.portal.webui.application.UIPortlet.invoke(UIPortlet.java:1014)
> 	at org.exoplatform.portal.webui.application.UIPortletActionListener$ProcessActionActionListener.execute(UIPortletActionListener.java:117)
> 	at org.exoplatform.webui.event.Event.broadcast(Event.java:97)
> 	at org.exoplatform.portal.webui.application.UIPortletLifecycle.processAction(UIPortletLifecycle.java:113)
> 	at org.exoplatform.portal.webui.application.UIPortletLifecycle.processAction(UIPortletLifecycle.java:56)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processAction(UIPortalApplicationLifecycle.java:73)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processAction(UIPortalApplicationLifecycle.java:36)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.UIApplication.processAction(UIApplication.java:123)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplication.processAction(UIPortalApplication.java:782)
> 	at org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:228)
> 	at org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:184)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:340)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:110)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:96)
> 	at org.gatein.portal.installer.PortalSetupFilter.doFilter(PortalSetupFilter.java:72)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:92)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:71)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:70)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:68)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:122)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.login.ConversationStateUpdateFilter.doFilter(ConversationStateUpdateFilter.java:66)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.web.security.impersonation.ImpersonationFilter.doFilter(ImpersonationFilter.java:84)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:122)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:55)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.security.oauth.webapi.OAuthDelegateFilter.doFilter(OAuthDelegateFilter.java:58)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.sso.integration.SSODelegateFilter.doFilter(SSODelegateFilter.java:60)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.portal.init.PortalCheckInitFilter.doFilter(PortalCheckInitFilter.java:66)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> 	at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:123)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.gatein.sso.agent.tomcat.ServletAccessValve.invoke(ServletAccessValve.java:55)
> 	at org.apache.catalina.core.StandardHostValve.__invoke(StandardHostValve.java:171)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:722)
> {code}
> => Expect: should reload new data after refresh form (no need re login) because this is an admin portlet, we rare to access to this portlet and dataset of membershiptype is usually small.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Mon Jul  7 03:36:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Mon, 7 Jul 2014 03:36:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3515) Should refresh data
 in Membership management form without relogin
In-Reply-To: <JIRA.12544565.1403488633000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544565.1403488633000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544565.1403488633000.43479.1404718584518@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trong Tran updated GTNPORTAL-3515:
----------------------------------

        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> Should refresh data in Membership management form without relogin
> -----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3515
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3515
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Tuyen Nguyen The
>            Priority: Minor
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>
> Use 2 browser to access to gatein:
> On browser 1
> + Access to gatein
> + Login with user root
> + Go to Users/Group and Roles/Membership management
> + Create new membership
> On browser 2:
> + Access to gatein
> + Login with user root
> + Go to Users/Group and Roles/Membership management -> see membership above => OK
> + Edit info of this membership
> On browser 1: Refresh Membership management form but do not see updated info of membership => NOK
> Go to browser 2: Delete this membership
> Go to browser 1:
> + Refresh Membership management form but still see this membership => NOK
> + Click Edit icon of this membership -> Unknown error (has exception)
> {code}
> [http-bio-8080-exec-1] ERROR portal:UIPortalApplication - Error during the processAction phase
> java.lang.NullPointerException
> 	at org.exoplatform.organization.webui.component.UIListMembershipType$EditMembershipActionListener.execute(UIListMembershipType.java:85)
> 	at org.exoplatform.webui.event.Event.broadcast(Event.java:97)
> 	at org.exoplatform.webui.core.lifecycle.Lifecycle.processAction(Lifecycle.java:51)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.lifecycle.UIApplicationLifecycle.processAction(UIApplicationLifecycle.java:53)
> 	at org.exoplatform.webui.core.lifecycle.UIApplicationLifecycle.processAction(UIApplicationLifecycle.java:30)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.UIApplication.processAction(UIApplication.java:123)
> 	at org.exoplatform.webui.application.portlet.PortletApplication.processAction(PortletApplication.java:152)
> 	at org.exoplatform.webui.application.portlet.PortletApplicationController.processAction(PortletApplicationController.java:88)
> 	at org.gatein.pc.portlet.impl.jsr168.PortletContainerImpl$Invoker.doFilter(PortletContainerImpl.java:581)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:109)
> 	at org.exoplatform.portal.application.ApplicationMonitoringFilter.doFilter(ApplicationMonitoringFilter.java:41)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:109)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:72)
> 	at org.gatein.pc.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:529)
> 	at org.gatein.pc.portlet.container.ContainerPortletDispatcher.invoke(ContainerPortletDispatcher.java:42)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.EventPayloadInterceptor.invoke(EventPayloadInterceptor.java:197)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.RequestAttributeConversationInterceptor.invoke(RequestAttributeConversationInterceptor.java:119)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.CCPPInterceptor.invoke(CCPPInterceptor.java:65)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor.access$201(ContextDispatcherInterceptor.java:46)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor$CallableImpl.call(ContextDispatcherInterceptor.java:119)
> 	at org.exoplatform.portal.webui.application.ExoServerContext$1.doCallback(ExoServerContext.java:49)
> 	at org.gatein.wci.command.CommandDispatcher$CallbackCommand.execute(CommandDispatcher.java:82)
> 	at org.gatein.wci.command.TomcatCommandDispatcher$1.execute(TomcatCommandDispatcher.java:61)
> 	at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.gatein.wci.command.CommandServlet.doGet(CommandServlet.java:135)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544)
> 	at org.gatein.wci.command.CommandServlet.include(CommandServlet.java:84)
> 	at org.gatein.wci.command.TomcatCommandDispatcher.include(TomcatCommandDispatcher.java:97)
> 	at org.gatein.wci.tomcat.TC7ServletContainerContext.include(TC7ServletContainerContext.java:113)
> 	at org.gatein.wci.ServletContainer.include(ServletContainer.java:395)
> 	at org.exoplatform.portal.webui.application.ExoServerContext.dispatch(ExoServerContext.java:45)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:65)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.exoplatform.portal.pc.aspects.PortletLifecyclePhaseInterceptor.invoke(PortletLifecyclePhaseInterceptor.java:30)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ValveInterceptor.invoke(ValveInterceptor.java:84)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.container.ContainerPortletInvoker.invoke(ContainerPortletInvoker.java:131)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:263)
> 	at org.gatein.pc.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:163)
> 	at org.gatein.pc.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:246)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.PortletCustomizationInterceptor.invoke(PortletCustomizationInterceptor.java:76)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:247)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.exoplatform.portal.webui.application.UIPortlet.invoke(UIPortlet.java:1014)
> 	at org.exoplatform.portal.webui.application.UIPortletActionListener$ProcessActionActionListener.execute(UIPortletActionListener.java:117)
> 	at org.exoplatform.webui.event.Event.broadcast(Event.java:97)
> 	at org.exoplatform.portal.webui.application.UIPortletLifecycle.processAction(UIPortletLifecycle.java:113)
> 	at org.exoplatform.portal.webui.application.UIPortletLifecycle.processAction(UIPortletLifecycle.java:56)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processAction(UIPortalApplicationLifecycle.java:73)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processAction(UIPortalApplicationLifecycle.java:36)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.UIApplication.processAction(UIApplication.java:123)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplication.processAction(UIPortalApplication.java:782)
> 	at org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:228)
> 	at org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:184)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:340)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:110)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:96)
> 	at org.gatein.portal.installer.PortalSetupFilter.doFilter(PortalSetupFilter.java:72)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:92)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:71)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:70)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:68)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:122)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.login.ConversationStateUpdateFilter.doFilter(ConversationStateUpdateFilter.java:66)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.web.security.impersonation.ImpersonationFilter.doFilter(ImpersonationFilter.java:84)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:122)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:55)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.security.oauth.webapi.OAuthDelegateFilter.doFilter(OAuthDelegateFilter.java:58)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.sso.integration.SSODelegateFilter.doFilter(SSODelegateFilter.java:60)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.portal.init.PortalCheckInitFilter.doFilter(PortalCheckInitFilter.java:66)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> 	at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:123)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.gatein.sso.agent.tomcat.ServletAccessValve.invoke(ServletAccessValve.java:55)
> 	at org.apache.catalina.core.StandardHostValve.__invoke(StandardHostValve.java:171)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:722)
> {code}
> => Expect: should reload new data after refresh form (no need re login) because this is an admin portlet, we rare to access to this portlet and dataset of membershiptype is usually small.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Mon Jul  7 03:38:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Mon, 7 Jul 2014 03:38:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3515) Should refresh data
 in Membership management form without relogin
In-Reply-To: <JIRA.12544565.1403488633000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544565.1403488633000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544565.1403488633000.43490.1404718704769@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12982511#comment-12982511 ] 

Trong Tran commented on GTNPORTAL-3515:
---------------------------------------

The PR https://github.com/gatein/gatein-portal/pull/883 breaks the Page Iterator functionality. It always return the first page when doing a refresh.

 I updated and pushed a proper fix at https://github.com/gatein/gatein-portal/commit/b8f95e800c98fe081aa8aba382ca48890a290de4

> Should refresh data in Membership management form without relogin
> -----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3515
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3515
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Tuyen Nguyen The
>            Priority: Minor
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>
> Use 2 browser to access to gatein:
> On browser 1
> + Access to gatein
> + Login with user root
> + Go to Users/Group and Roles/Membership management
> + Create new membership
> On browser 2:
> + Access to gatein
> + Login with user root
> + Go to Users/Group and Roles/Membership management -> see membership above => OK
> + Edit info of this membership
> On browser 1: Refresh Membership management form but do not see updated info of membership => NOK
> Go to browser 2: Delete this membership
> Go to browser 1:
> + Refresh Membership management form but still see this membership => NOK
> + Click Edit icon of this membership -> Unknown error (has exception)
> {code}
> [http-bio-8080-exec-1] ERROR portal:UIPortalApplication - Error during the processAction phase
> java.lang.NullPointerException
> 	at org.exoplatform.organization.webui.component.UIListMembershipType$EditMembershipActionListener.execute(UIListMembershipType.java:85)
> 	at org.exoplatform.webui.event.Event.broadcast(Event.java:97)
> 	at org.exoplatform.webui.core.lifecycle.Lifecycle.processAction(Lifecycle.java:51)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.lifecycle.UIApplicationLifecycle.processAction(UIApplicationLifecycle.java:53)
> 	at org.exoplatform.webui.core.lifecycle.UIApplicationLifecycle.processAction(UIApplicationLifecycle.java:30)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.UIApplication.processAction(UIApplication.java:123)
> 	at org.exoplatform.webui.application.portlet.PortletApplication.processAction(PortletApplication.java:152)
> 	at org.exoplatform.webui.application.portlet.PortletApplicationController.processAction(PortletApplicationController.java:88)
> 	at org.gatein.pc.portlet.impl.jsr168.PortletContainerImpl$Invoker.doFilter(PortletContainerImpl.java:581)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:109)
> 	at org.exoplatform.portal.application.ApplicationMonitoringFilter.doFilter(ApplicationMonitoringFilter.java:41)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:109)
> 	at org.gatein.pc.portlet.impl.jsr168.api.FilterChainImpl.doFilter(FilterChainImpl.java:72)
> 	at org.gatein.pc.portlet.impl.jsr168.PortletContainerImpl.dispatch(PortletContainerImpl.java:529)
> 	at org.gatein.pc.portlet.container.ContainerPortletDispatcher.invoke(ContainerPortletDispatcher.java:42)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.EventPayloadInterceptor.invoke(EventPayloadInterceptor.java:197)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.RequestAttributeConversationInterceptor.invoke(RequestAttributeConversationInterceptor.java:119)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.CCPPInterceptor.invoke(CCPPInterceptor.java:65)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.bridge.BridgeInterceptor.invoke(BridgeInterceptor.java:49)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor.access$201(ContextDispatcherInterceptor.java:46)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor$CallableImpl.call(ContextDispatcherInterceptor.java:119)
> 	at org.exoplatform.portal.webui.application.ExoServerContext$1.doCallback(ExoServerContext.java:49)
> 	at org.gatein.wci.command.CommandDispatcher$CallbackCommand.execute(CommandDispatcher.java:82)
> 	at org.gatein.wci.command.TomcatCommandDispatcher$1.execute(TomcatCommandDispatcher.java:61)
> 	at sun.reflect.GeneratedMethodAccessor118.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:601)
> 	at org.gatein.wci.command.CommandServlet.doGet(CommandServlet.java:135)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:749)
> 	at org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:605)
> 	at org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:544)
> 	at org.gatein.wci.command.CommandServlet.include(CommandServlet.java:84)
> 	at org.gatein.wci.command.TomcatCommandDispatcher.include(TomcatCommandDispatcher.java:97)
> 	at org.gatein.wci.tomcat.TC7ServletContainerContext.include(TC7ServletContainerContext.java:113)
> 	at org.gatein.wci.ServletContainer.include(ServletContainer.java:395)
> 	at org.exoplatform.portal.webui.application.ExoServerContext.dispatch(ExoServerContext.java:45)
> 	at org.gatein.pc.portlet.aspects.ContextDispatcherInterceptor.invoke(ContextDispatcherInterceptor.java:65)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.exoplatform.portal.pc.aspects.PortletLifecyclePhaseInterceptor.invoke(PortletLifecyclePhaseInterceptor.java:30)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.SecureTransportInterceptor.invoke(SecureTransportInterceptor.java:69)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ValveInterceptor.invoke(ValveInterceptor.java:84)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.container.ContainerPortletInvoker.invoke(ContainerPortletInvoker.java:131)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.state.producer.ProducerPortletInvoker.invoke(ProducerPortletInvoker.java:263)
> 	at org.gatein.pc.federation.impl.FederatedPortletInvokerService.invoke(FederatedPortletInvokerService.java:163)
> 	at org.gatein.pc.federation.impl.FederatingPortletInvokerService.invoke(FederatingPortletInvokerService.java:246)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.PortletCustomizationInterceptor.invoke(PortletCustomizationInterceptor.java:76)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.gatein.pc.portlet.aspects.ConsumerCacheInterceptor.invoke(ConsumerCacheInterceptor.java:247)
> 	at org.gatein.pc.portlet.PortletInvokerInterceptor.invoke(PortletInvokerInterceptor.java:111)
> 	at org.exoplatform.portal.webui.application.UIPortlet.invoke(UIPortlet.java:1014)
> 	at org.exoplatform.portal.webui.application.UIPortletActionListener$ProcessActionActionListener.execute(UIPortletActionListener.java:117)
> 	at org.exoplatform.webui.event.Event.broadcast(Event.java:97)
> 	at org.exoplatform.portal.webui.application.UIPortletLifecycle.processAction(UIPortletLifecycle.java:113)
> 	at org.exoplatform.portal.webui.application.UIPortletLifecycle.processAction(UIPortletLifecycle.java:56)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processAction(UIPortalApplicationLifecycle.java:73)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplicationLifecycle.processAction(UIPortalApplicationLifecycle.java:36)
> 	at org.exoplatform.webui.core.UIComponent.processAction(UIComponent.java:125)
> 	at org.exoplatform.webui.core.UIApplication.processAction(UIApplication.java:123)
> 	at org.exoplatform.portal.webui.workspace.UIPortalApplication.processAction(UIPortalApplication.java:782)
> 	at org.exoplatform.portal.application.PortalRequestHandler.processRequest(PortalRequestHandler.java:228)
> 	at org.exoplatform.portal.application.PortalRequestHandler.execute(PortalRequestHandler.java:184)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:340)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:110)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:133)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:96)
> 	at org.gatein.portal.installer.PortalSetupFilter.doFilter(PortalSetupFilter.java:72)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:92)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:71)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:70)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:68)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:122)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.login.ConversationStateUpdateFilter.doFilter(ConversationStateUpdateFilter.java:66)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.web.security.impersonation.ImpersonationFilter.doFilter(ImpersonationFilter.java:84)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:122)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:55)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.security.oauth.webapi.OAuthDelegateFilter.doFilter(OAuthDelegateFilter.java:58)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.sso.integration.SSODelegateFilter.doFilter(SSODelegateFilter.java:60)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.gatein.portal.init.PortalCheckInitFilter.doFilter(PortalCheckInitFilter.java:66)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> 	at org.apache.catalina.core.StandardContextValve.__invoke(StandardContextValve.java:123)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
> 	at org.gatein.sso.agent.tomcat.ServletAccessValve.invoke(ServletAccessValve.java:55)
> 	at org.apache.catalina.core.StandardHostValve.__invoke(StandardHostValve.java:171)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> 	at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
> 	at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
> 	at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
> 	at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:722)
> {code}
> => Expect: should reload new data after refresh form (no need re login) because this is an admin portlet, we rare to access to this portlet and dataset of membershiptype is usually small.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  9 08:16:26 2014
From: issues at jboss.org (Marwen Trabelsi (JIRA))
Date: Wed, 9 Jul 2014 08:16:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-30) Update picketlink
 dependency to be able to use x509Data element as a signature
In-Reply-To: <JIRA.12545952.1404908081174@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545952.1404908081174@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545952.1404908081174.50200.1404908186925@jira02.app.mwc.hst.phx2.redhat.com>

Marwen Trabelsi created GTNSSO-30:
-------------------------------------

             Summary: Update picketlink dependency to be able to use x509Data element as a signature
                 Key: GTNSSO-30
                 URL: https://issues.jboss.org/browse/GTNSSO-30
             Project: GateIn SSO
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
    Affects Versions: 1.4.2.Final
            Reporter: Marwen Trabelsi
            Assignee: Marek Posolda


The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandated receiving x509Data to process the response.

This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix is needed.




--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  9 08:16:28 2014
From: issues at jboss.org (Marwen Trabelsi (JIRA))
Date: Wed, 9 Jul 2014 08:16:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-30) Update picketlink
 dependency to be able to use x509Data element as a signature
In-Reply-To: <JIRA.12545952.1404908081000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545952.1404908081000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545952.1404908081000.50212.1404908188020@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNSSO-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marwen Trabelsi updated GTNSSO-30:
----------------------------------

    Description: 
The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandate receiving x509Data as the KeyInfo to process the response.

This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix is needed.


  was:
The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandated receiving x509Data to process the response.

This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix is needed.




> Update picketlink dependency to be able to use x509Data element as a signature
> ------------------------------------------------------------------------------
>
>                 Key: GTNSSO-30
>                 URL: https://issues.jboss.org/browse/GTNSSO-30
>             Project: GateIn SSO
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.2.Final
>            Reporter: Marwen Trabelsi
>            Assignee: Marek Posolda
>
> The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
> This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandate receiving x509Data as the KeyInfo to process the response.
> This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix is needed.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  9 08:16:28 2014
From: issues at jboss.org (Marwen Trabelsi (JIRA))
Date: Wed, 9 Jul 2014 08:16:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-30) Update picketlink
 dependency to be able to use x509Data element as a signature
In-Reply-To: <JIRA.12545952.1404908081000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545952.1404908081000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545952.1404908081000.50216.1404908188322@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNSSO-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marwen Trabelsi updated GTNSSO-30:
----------------------------------

    Description: 
The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandate receiving x509Data as the KeyInfo to process the response.

This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix (*2.6.0*) is needed.


  was:
The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandate receiving x509Data as the KeyInfo to process the response.

This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix is needed.




> Update picketlink dependency to be able to use x509Data element as a signature
> ------------------------------------------------------------------------------
>
>                 Key: GTNSSO-30
>                 URL: https://issues.jboss.org/browse/GTNSSO-30
>             Project: GateIn SSO
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.2.Final
>            Reporter: Marwen Trabelsi
>            Assignee: Marek Posolda
>
> The current generated SAMLResponse by GateIn only carries Public Key (modulus and exponent) in the KeyInfo element and cannot carry an x509Data (with the x509Certificate).
> This results in a compatibility issue when setting up the GateIn instance as a Service Provider with a third party IdP that mandate receiving x509Data as the KeyInfo to process the response.
> This feature has already been handled and fixed in PLINK-146, thus only an upgrade to the version underlying the fix (*2.6.0*) is needed.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul  9 09:10:24 2014
From: issues at jboss.org (Ahmed Zaoui (JIRA))
Date: Wed, 9 Jul 2014 09:10:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3512) Don't swallow
 exception when happens on IDM API
In-Reply-To: <JIRA.12543722.1402653655000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543722.1402653655000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543722.1402653655000.50398.1404911424389@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ahmed Zaoui updated GTNPORTAL-3512:
-----------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/885


> 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.5.10.Final, 3.6.3.Final, 3.7.1.Final, 3.8.2.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)

From issues at jboss.org  Thu Jul 10 04:39:24 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Thu, 10 Jul 2014 04:39:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-31) CAS 4.0.0 can not start
 with gatein-cas-plugin
In-Reply-To: <JIRA.12546018.1404981467894@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546018.1404981467894@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546018.1404981467894.52196.1404981564404@jira02.app.mwc.hst.phx2.redhat.com>

Tuyen Nguyen The created GTNSSO-31:
--------------------------------------

             Summary: CAS 4.0.0 can not start with gatein-cas-plugin
                 Key: GTNSSO-31
                 URL: https://issues.jboss.org/browse/GTNSSO-31
             Project: GateIn SSO
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Tuyen Nguyen The
            Assignee: Marek Posolda


- Download CAS 4.0.0 at: http://www.jasig.org/cas/download
- Configure CAS server following by document at https://docs.jboss.org/author/display/GTNPORTAL37/Central+Authentication+Service+(CAS)

When start apache-tomcat with cas.war, we will meet below exception and cas.war is not deployed.

{code}
2014-07-10 14:44:28,065 ERROR [org.springframework.web.context.ContextLoader] - <Context initialization failed>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.gatein.sso.cas.plugin.AuthenticationPlugin#0' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
	at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389)
	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody0(SafeContextLoaderListener.java:75)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody1$advice(SafeContextLoaderListener.java:54)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized(SafeContextLoaderListener.java:1)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
	at java.lang.Class.privateGetPublicMethods(Class.java:2571)
	at java.lang.Class.getMethods(Class.java:1429)
	at org.springframework.beans.ExtendedBeanInfoFactory.supports(ExtendedBeanInfoFactory.java:53)
	at org.springframework.beans.ExtendedBeanInfoFactory.getBeanInfo(ExtendedBeanInfoFactory.java:44)
	at org.springframework.beans.CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:234)
	at org.springframework.beans.CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:150)
	at org.springframework.beans.BeanWrapperImpl.getCachedIntrospectionResults(BeanWrapperImpl.java:321)
	at org.springframework.beans.BeanWrapperImpl.getPropertyDescriptors(BeanWrapperImpl.java:328)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1303)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1283)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1141)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
	... 22 more
Caused by: java.lang.ClassNotFoundException: org.jasig.cas.authentication.principal.UsernamePasswordCredentials
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
	... 36 more
	
{code}

It's because at version 4.0.0, CAS was refactored many thing, one of them is the class 
{code}
org.jasig.cas.authentication.principal.UsernamePasswordCredentials
{code} 
was changed to 
{code}
org.jasig.cas.authentication.principal.UsernamePasswordCredentials
{code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 04:43:24 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Thu, 10 Jul 2014 04:43:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-31) CAS 4.0.0 can not start
 with gatein-cas-plugin
In-Reply-To: <JIRA.12546018.1404981467000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546018.1404981467000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546018.1404981467000.52209.1404981804859@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNSSO-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tuyen Nguyen The updated GTNSSO-31:
-----------------------------------

    Description: 
- Download CAS 4.0.0 at: http://www.jasig.org/cas/download
- Configure CAS server following by document at https://docs.jboss.org/author/display/GTNPORTAL37/Central+Authentication+Service+(CAS)

When start apache-tomcat with cas.war, we will meet below exception and cas.war is not deployed.

{code}
2014-07-10 14:44:28,065 ERROR [org.springframework.web.context.ContextLoader] - <Context initialization failed>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.gatein.sso.cas.plugin.AuthenticationPlugin#0' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
	at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389)
	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody0(SafeContextLoaderListener.java:75)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody1$advice(SafeContextLoaderListener.java:54)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized(SafeContextLoaderListener.java:1)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
	at java.lang.Class.privateGetPublicMethods(Class.java:2571)
	at java.lang.Class.getMethods(Class.java:1429)
	at org.springframework.beans.ExtendedBeanInfoFactory.supports(ExtendedBeanInfoFactory.java:53)
	at org.springframework.beans.ExtendedBeanInfoFactory.getBeanInfo(ExtendedBeanInfoFactory.java:44)
	at org.springframework.beans.CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:234)
	at org.springframework.beans.CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:150)
	at org.springframework.beans.BeanWrapperImpl.getCachedIntrospectionResults(BeanWrapperImpl.java:321)
	at org.springframework.beans.BeanWrapperImpl.getPropertyDescriptors(BeanWrapperImpl.java:328)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1303)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1283)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1141)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
	... 22 more
Caused by: java.lang.ClassNotFoundException: org.jasig.cas.authentication.principal.UsernamePasswordCredentials
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
	... 36 more
	
{code}

It's because at version 4.0.0, CAS was refactored many thing, one of them is in the class org.jasig.cas.authentication.handler.support.AbstractUsernamePasswordAuthenticationHandler, method
{code}
protected abstract boolean authenticateUsernamePasswordInternal(org.jasig.cas.authentication.principal.UsernamePasswordCredentials usernamePasswordCredentials) throws org.jasig.cas.authentication.handler.AuthenticationException;
{code} 
was changed to 
{code}
protected abstract org.jasig.cas.authentication.HandlerResult authenticateUsernamePasswordInternal(org.jasig.cas.authentication.UsernamePasswordCredential usernamePasswordCredential) throws java.security.GeneralSecurityException, org.jasig.cas.authentication.PreventedException;
{code}

  was:
- Download CAS 4.0.0 at: http://www.jasig.org/cas/download
- Configure CAS server following by document at https://docs.jboss.org/author/display/GTNPORTAL37/Central+Authentication+Service+(CAS)

When start apache-tomcat with cas.war, we will meet below exception and cas.war is not deployed.

{code}
2014-07-10 14:44:28,065 ERROR [org.springframework.web.context.ContextLoader] - <Context initialization failed>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.gatein.sso.cas.plugin.AuthenticationPlugin#0' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
	at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389)
	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody0(SafeContextLoaderListener.java:75)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody1$advice(SafeContextLoaderListener.java:54)
	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized(SafeContextLoaderListener.java:1)
	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
	at java.lang.Class.getDeclaredMethods0(Native Method)
	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
	at java.lang.Class.privateGetPublicMethods(Class.java:2571)
	at java.lang.Class.getMethods(Class.java:1429)
	at org.springframework.beans.ExtendedBeanInfoFactory.supports(ExtendedBeanInfoFactory.java:53)
	at org.springframework.beans.ExtendedBeanInfoFactory.getBeanInfo(ExtendedBeanInfoFactory.java:44)
	at org.springframework.beans.CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:234)
	at org.springframework.beans.CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:150)
	at org.springframework.beans.BeanWrapperImpl.getCachedIntrospectionResults(BeanWrapperImpl.java:321)
	at org.springframework.beans.BeanWrapperImpl.getPropertyDescriptors(BeanWrapperImpl.java:328)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1303)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1283)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1141)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
	... 22 more
Caused by: java.lang.ClassNotFoundException: org.jasig.cas.authentication.principal.UsernamePasswordCredentials
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
	... 36 more
	
{code}

It's because at version 4.0.0, CAS was refactored many thing, one of them is the class 
{code}
org.jasig.cas.authentication.principal.UsernamePasswordCredentials
{code} 
was changed to 
{code}
org.jasig.cas.authentication.principal.UsernamePasswordCredentials
{code}



> CAS 4.0.0 can not start with gatein-cas-plugin
> ----------------------------------------------
>
>                 Key: GTNSSO-31
>                 URL: https://issues.jboss.org/browse/GTNSSO-31
>             Project: GateIn SSO
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Marek Posolda
>
> - Download CAS 4.0.0 at: http://www.jasig.org/cas/download
> - Configure CAS server following by document at https://docs.jboss.org/author/display/GTNPORTAL37/Central+Authentication+Service+(CAS)
> When start apache-tomcat with cas.war, we will meet below exception and cas.war is not deployed.
> {code}
> 2014-07-10 14:44:28,065 ERROR [org.springframework.web.context.ContextLoader] - <Context initialization failed>
> org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.gatein.sso.cas.plugin.AuthenticationPlugin#0' defined in ServletContext resource [/WEB-INF/deployerConfigContext.xml]: Initialization of bean failed; nested exception is java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:529)
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:458)
> 	at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:296)
> 	at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:223)
> 	at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:293)
> 	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
> 	at org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:628)
> 	at org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:932)
> 	at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:479)
> 	at org.springframework.web.context.ContextLoader.configureAndRefreshWebApplicationContext(ContextLoader.java:389)
> 	at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:294)
> 	at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:112)
> 	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody0(SafeContextLoaderListener.java:75)
> 	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized_aroundBody1$advice(SafeContextLoaderListener.java:54)
> 	at org.jasig.cas.web.init.SafeContextLoaderListener.contextInitialized(SafeContextLoaderListener.java:1)
> 	at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4723)
> 	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
> 	at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
> 	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> 	at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.NoClassDefFoundError: org/jasig/cas/authentication/principal/UsernamePasswordCredentials
> 	at java.lang.Class.getDeclaredMethods0(Native Method)
> 	at java.lang.Class.privateGetDeclaredMethods(Class.java:2451)
> 	at java.lang.Class.privateGetPublicMethods(Class.java:2571)
> 	at java.lang.Class.getMethods(Class.java:1429)
> 	at org.springframework.beans.ExtendedBeanInfoFactory.supports(ExtendedBeanInfoFactory.java:53)
> 	at org.springframework.beans.ExtendedBeanInfoFactory.getBeanInfo(ExtendedBeanInfoFactory.java:44)
> 	at org.springframework.beans.CachedIntrospectionResults.<init>(CachedIntrospectionResults.java:234)
> 	at org.springframework.beans.CachedIntrospectionResults.forClass(CachedIntrospectionResults.java:150)
> 	at org.springframework.beans.BeanWrapperImpl.getCachedIntrospectionResults(BeanWrapperImpl.java:321)
> 	at org.springframework.beans.BeanWrapperImpl.getPropertyDescriptors(BeanWrapperImpl.java:328)
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1303)
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.filterPropertyDescriptorsForDependencyCheck(AbstractAutowireCapableBeanFactory.java:1283)
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.populateBean(AbstractAutowireCapableBeanFactory.java:1141)
> 	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519)
> 	... 22 more
> Caused by: java.lang.ClassNotFoundException: org.jasig.cas.authentication.principal.UsernamePasswordCredentials
> 	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1676)
> 	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521)
> 	... 36 more
> 	
> {code}
> It's because at version 4.0.0, CAS was refactored many thing, one of them is in the class org.jasig.cas.authentication.handler.support.AbstractUsernamePasswordAuthenticationHandler, method
> {code}
> protected abstract boolean authenticateUsernamePasswordInternal(org.jasig.cas.authentication.principal.UsernamePasswordCredentials usernamePasswordCredentials) throws org.jasig.cas.authentication.handler.AuthenticationException;
> {code} 
> was changed to 
> {code}
> protected abstract org.jasig.cas.authentication.HandlerResult authenticateUsernamePasswordInternal(org.jasig.cas.authentication.UsernamePasswordCredential usernamePasswordCredential) throws java.security.GeneralSecurityException, org.jasig.cas.authentication.PreventedException;
> {code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 07:01:28 2014
From: issues at jboss.org (Ali Hamdi (JIRA))
Date: Thu, 10 Jul 2014 07:01:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-28) realm is wrong adds an
 extra g in the realm name with OpenAM 11
In-Reply-To: <JIRA.12540213.1399536877000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540213.1399536877000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540213.1399536877000.52599.1404990088084@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNSSO-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983835#comment-12983835 ] 

Ali Hamdi commented on GTNSSO-28:
---------------------------------

This issue is caused by this bug on OpenAm side : https://bugster.forgerock.org/jira/browse/OPENAM-1539

> realm is wrong adds an extra g in the realm name with OpenAM 11
> ---------------------------------------------------------------
>
>                 Key: GTNSSO-28
>                 URL: https://issues.jboss.org/browse/GTNSSO-28
>             Project: GateIn SSO
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.Beta01
>         Environment: Using OpenAM 11 - using the plugin with Exo Platform but imagine this is probably the same for anything using gatein-sso for CDSSO with OpenAM 11
>            Reporter: Michael McKinsey
>            Assignee: Marek Posolda
>             Fix For: 1.4.3.Final
>
>
> The realm name is coming up wrong with an extra g which I believe is causing the error #403x
> https://./openam/cdcservlet?realm=gatein&goto=https%3A%2F%2F.%3A8443%2Fportal%2Finitiatessologin&ProviderID=https%3A%2F%2F.%3A8443%2Fportal%2Finitiatessologin%2F%3FRealm%3Dggatein&RequestID=71288&IssueInstant=2014-05-08T01%3A10%3A30Z&MajorVersion=1&MinorVersion=0
> notice realm is ggatein
> I found a reference to the extra g:
> https://github.com/gatein/gatein-sso/blob/b3b0e3fb9fd5d9498a97e89357603d1a0b0d800a/agent/src/main/java/org/gatein/sso/agent/filter/OpenSSOCDLoginRedirectFilter.java
> It says:
> // We need to use Realm=g because of bug (or strange behaviour) of OpenAM, which cuts first character of realmName during parsing
> String providerId = agentUrl + "/?Realm=g" + openSSORealm;
> I am guessing this was needed with OpenAM 10 but is causing an error with OpenAM 11.  I was trying to fix this myself but I can't get gatein-sso to build in my environment just yet.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 07:01:28 2014
From: issues at jboss.org (Ali Hamdi (JIRA))
Date: Thu, 10 Jul 2014 07:01:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-28) realm is wrong adds an
 extra g in the realm name with OpenAM 11
In-Reply-To: <JIRA.12540213.1399536877000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540213.1399536877000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540213.1399536877000.52602.1404990088295@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNSSO-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983835#comment-12983835 ] 

Ali Hamdi edited comment on GTNSSO-28 at 7/10/14 7:00 AM:
----------------------------------------------------------

This issue is caused by this bug on OpenAM side : https://bugster.forgerock.org/jira/browse/OPENAM-1539
This was fixed for OpenAM 10.1 and OpenAM 11


was (Author: ali_hamdi):
This issue is caused by this bug on OpenAm side : https://bugster.forgerock.org/jira/browse/OPENAM-1539

> realm is wrong adds an extra g in the realm name with OpenAM 11
> ---------------------------------------------------------------
>
>                 Key: GTNSSO-28
>                 URL: https://issues.jboss.org/browse/GTNSSO-28
>             Project: GateIn SSO
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.Beta01
>         Environment: Using OpenAM 11 - using the plugin with Exo Platform but imagine this is probably the same for anything using gatein-sso for CDSSO with OpenAM 11
>            Reporter: Michael McKinsey
>            Assignee: Marek Posolda
>             Fix For: 1.4.3.Final
>
>
> The realm name is coming up wrong with an extra g which I believe is causing the error #403x
> https://./openam/cdcservlet?realm=gatein&goto=https%3A%2F%2F.%3A8443%2Fportal%2Finitiatessologin&ProviderID=https%3A%2F%2F.%3A8443%2Fportal%2Finitiatessologin%2F%3FRealm%3Dggatein&RequestID=71288&IssueInstant=2014-05-08T01%3A10%3A30Z&MajorVersion=1&MinorVersion=0
> notice realm is ggatein
> I found a reference to the extra g:
> https://github.com/gatein/gatein-sso/blob/b3b0e3fb9fd5d9498a97e89357603d1a0b0d800a/agent/src/main/java/org/gatein/sso/agent/filter/OpenSSOCDLoginRedirectFilter.java
> It says:
> // We need to use Realm=g because of bug (or strange behaviour) of OpenAM, which cuts first character of realmName during parsing
> String providerId = agentUrl + "/?Realm=g" + openSSORealm;
> I am guessing this was needed with OpenAM 10 but is causing an error with OpenAM 11.  I was trying to fix this myself but I can't get gatein-sso to build in my environment just yet.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 07:15:26 2014
From: issues at jboss.org (Ali Hamdi (JIRA))
Date: Thu, 10 Jul 2014 07:15:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-28) realm is wrong adds an
 extra g in the realm name with OpenAM 11
In-Reply-To: <JIRA.12540213.1399536877000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540213.1399536877000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540213.1399536877000.52643.1404990926402@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNSSO-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983841#comment-12983841 ] 

Ali Hamdi commented on GTNSSO-28:
---------------------------------

Here is a Pull request that fixes the issue : https://github.com/gatein/gatein-sso/pull/5

> realm is wrong adds an extra g in the realm name with OpenAM 11
> ---------------------------------------------------------------
>
>                 Key: GTNSSO-28
>                 URL: https://issues.jboss.org/browse/GTNSSO-28
>             Project: GateIn SSO
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 1.4.0.Beta01
>         Environment: Using OpenAM 11 - using the plugin with Exo Platform but imagine this is probably the same for anything using gatein-sso for CDSSO with OpenAM 11
>            Reporter: Michael McKinsey
>            Assignee: Marek Posolda
>             Fix For: 1.4.3.Final
>
>
> The realm name is coming up wrong with an extra g which I believe is causing the error #403x
> https://./openam/cdcservlet?realm=gatein&goto=https%3A%2F%2F.%3A8443%2Fportal%2Finitiatessologin&ProviderID=https%3A%2F%2F.%3A8443%2Fportal%2Finitiatessologin%2F%3FRealm%3Dggatein&RequestID=71288&IssueInstant=2014-05-08T01%3A10%3A30Z&MajorVersion=1&MinorVersion=0
> notice realm is ggatein
> I found a reference to the extra g:
> https://github.com/gatein/gatein-sso/blob/b3b0e3fb9fd5d9498a97e89357603d1a0b0d800a/agent/src/main/java/org/gatein/sso/agent/filter/OpenSSOCDLoginRedirectFilter.java
> It says:
> // We need to use Realm=g because of bug (or strange behaviour) of OpenAM, which cuts first character of realmName during parsing
> String providerId = agentUrl + "/?Realm=g" + openSSORealm;
> I am guessing this was needed with OpenAM 10 but is causing an error with OpenAM 11.  I was trying to fix this myself but I can't get gatein-sso to build in my environment just yet.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 08:51:26 2014
From: issues at jboss.org (Nicolas Filotto (JIRA))
Date: Thu, 10 Jul 2014 08:51:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3518) Use a variable to
	enable the sequence
In-Reply-To: <JIRA.12546048.1404996658763@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546048.1404996658763@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546048.1404996658763.52924.1404996686572@jira02.app.mwc.hst.phx2.redhat.com>

Nicolas Filotto created GTNPORTAL-3518:
------------------------------------------

             Summary: Use a variable to enable the sequence
                 Key: GTNPORTAL-3518
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3518
             Project: GateIn Portal
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
          Components: JCR integration
    Affects Versions: 3.8.2.Final
            Reporter: Nicolas Filotto
             Fix For: 3.8.5.Final, 3.9.0.Final


Starting from eXo JCR 1.16.0 Alpha4, we have an improvement (aka https://jira.exoplatform.org/browse/JCR-2262) that allows to provide a better scalability in term of total amount of sub nodes that a node can have without affecting the performances, indeed with big tables the performances get worse especially when we have a node with a lot of sub nodes so to push the scalability limit, eXo JCR can now rely on sequences. 

The sequences can be enabled thanks to a new parameter in the data container configuration of the workspace called {{use-sequence-for-order-number}}, by default it is set to {{auto}} so it will be enabled on all the databases on which we know that the sequences help to improve the performances and the scalability such as on Oracle and PostgreSQL, but also on H2 and HSQLDB.

Unfortunately, this improvement causes a regression which is (https://jira.exoplatform.org/browse/JCR-2322), so as workaround we can configure this parameter using a variable with {{false}} as default value, this way once the bug will be fixed, we will be able to set it back to the default value which is {{auto}}.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 10:50:24 2014
From: issues at jboss.org (Nicolas Filotto (JIRA))
Date: Thu, 10 Jul 2014 10:50:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3517) Cannot start Gatein
 Portal with MySQL in UTF-8
In-Reply-To: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12545292.1404279719000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545292.1404279719000.53512.1405003824502@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983960#comment-12983960 ] 

Nicolas Filotto commented on GTNPORTAL-3517:
--------------------------------------------

The PR needs to be updated according to my remarks that can be found here https://jira.exoplatform.org/browse/EXOGTN-1833?focusedCommentId=316638&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-316638

> Cannot start Gatein Portal with MySQL in UTF-8
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3517
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3517
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> If we want to use Gatein Portal in UTF-8 mode with MySQL, even if we configure the dialect to mysql-utf8, we get issues of type:
> {code}
> Caused by: org.jboss.cache.CacheException: Unable to start cache loaders
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:470) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	... 81 common frames omitted
> Caused by: com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Specified key was too long; max key length is 1000 bytes
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.6.0_45]
> 	at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) ~[na:1.6.0_45]
> 	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) ~[na:1.6.0_45]
> 	at java.lang.reflect.Constructor.newInstance(Constructor.java:513) ~[na:1.6.0_45]
> 	at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.Util.getInstance(Util.java:386) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1052) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4098) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:4030) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2490) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2651) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2671) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1749) ~[mysql-connector-java-5.1.19.jar:na]
> 	at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1666) ~[mysql-connector-java-5.1.19.jar:na]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.apache.tomcat.dbcp.dbcp.DelegatingStatement.executeUpdate(DelegatingStatement.java:228) ~[tomcat-dbcp.jar:7.0.42]
> 	at org.jboss.cache.loader.AdjListJDBCCacheLoader.start(AdjListJDBCCacheLoader.java:300) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.jboss.cache.loader.JDBCCacheLoader.start(JDBCCacheLoader.java:396) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> 	at org.exoplatform.services.jcr.impl.core.lock.jbosscache.ControllerCacheLoader.start(ControllerCacheLoader.java:312) ~[exo.jcr.component.core-1.15.8-GA-SNAPSHOT.jar:1.15.8-GA-SNAPSHOT]
> 	at org.jboss.cache.loader.CacheLoaderManager.startCacheLoader(CacheLoaderManager.java:464) ~[jbosscache-core-3.2.7.GA.jar:3.2.7.GA]
> {code}
> NB: The db schema has been created using the next command:
> {code}
> CREATE DATABASE plf_jcr_utf8 DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin; 
> {code}
> To make Gatein Portal work with MySQL in UTF-8, we need [JCR-2312|https://jira.exoplatform.org/browse/JCR-2312] and add new parameter introduced from JCR issue in the configuration of the lock manager which is infinispan-cl-cache.jdbc.dialect in case of infinispan and jbosscache-cl-cache.jdbc.dialect in case of JBC.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 10 14:00:26 2014
From: issues at jboss.org (Nicolas Filotto (JIRA))
Date: Thu, 10 Jul 2014 14:00:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3518) Use a variable to
	enable the sequence
In-Reply-To: <JIRA.12546048.1404996658000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546048.1404996658000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546048.1404996658000.53909.1405015226016@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nicolas Filotto updated GTNPORTAL-3518:
---------------------------------------

    Git Pull Request: https://github.com/gatein/gatein-portal/pull/886


> Use a variable to enable the sequence
> -------------------------------------
>
>                 Key: GTNPORTAL-3518
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3518
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JCR integration
>    Affects Versions: 3.8.2.Final
>            Reporter: Nicolas Filotto
>             Fix For: 3.8.5.Final, 3.9.0.Final
>
>
> Starting from eXo JCR 1.16.0 Alpha4, we have an improvement (aka https://jira.exoplatform.org/browse/JCR-2262) that allows to provide a better scalability in term of total amount of sub nodes that a node can have without affecting the performances, indeed with big tables the performances get worse especially when we have a node with a lot of sub nodes so to push the scalability limit, eXo JCR can now rely on sequences. 
> The sequences can be enabled thanks to a new parameter in the data container configuration of the workspace called {{use-sequence-for-order-number}}, by default it is set to {{auto}} so it will be enabled on all the databases on which we know that the sequences help to improve the performances and the scalability such as on Oracle and PostgreSQL, but also on H2 and HSQLDB.
> Unfortunately, this improvement causes a regression which is (https://jira.exoplatform.org/browse/JCR-2322), so as workaround we can configure this parameter using a variable with {{false}} as default value, this way once the bug will be fixed, we will be able to set it back to the default value which is {{auto}}.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Fri Jul 11 03:38:24 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Fri, 11 Jul 2014 03:38:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3519) "Import applications"
 fails when remote portlet name clashes with local portlet
In-Reply-To: <JIRA.12546150.1405064271257@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546150.1405064271257@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546150.1405064271257.55115.1405064304641@jira02.app.mwc.hst.phx2.redhat.com>

Juraci Paix?o Kr?hling created GTNPORTAL-3519:
-------------------------------------------------

             Summary: "Import applications" fails when remote portlet name clashes with local portlet
                 Key: GTNPORTAL-3519
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3519
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Juraci Paix?o Kr?hling
            Assignee: Juraci Paix?o Kr?hling


The "import applications" on the application registry fails when there's a remote portlet with the same name as a local portlet, due to "unknown error" on the user interface, and "Cannot create a content with a content id ... with an existing different content id" in the logs. 

More details on BZ#1117813 . 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:40:24 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Fri, 11 Jul 2014 09:40:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-378) WSRP Producer is missing
 distributable tag
In-Reply-To: <JIRA.12546193.1405085989564@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546193.1405085989564@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546193.1405085989564.56102.1405086024178@jira02.app.mwc.hst.phx2.redhat.com>

Juraci Paix?o Kr?hling created GTNWSRP-378:
----------------------------------------------

             Summary: WSRP Producer is missing distributable tag
                 Key: GTNWSRP-378
                 URL: https://issues.jboss.org/browse/GTNWSRP-378
             Project: GateIn WSRP
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Producer
            Reporter: Juraci Paix?o Kr?hling
            Assignee: Juraci Paix?o Kr?hling


See BZ#1115512 . The WSRP Producer WAR seems to be missing the <distributable/> tag on web.xml , causing session replication to not work for communication between consumer and producer. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:44:25 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Fri, 11 Jul 2014 09:44:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-378) WSRP Producer is missing
 distributable tag
In-Reply-To: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546193.1405085989000.56110.1405086265617@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNWSRP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juraci Paix?o Kr?hling updated GTNWSRP-378:
-------------------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/gatein/gatein-wsrp/pull/94


> WSRP Producer is missing distributable tag
> ------------------------------------------
>
>                 Key: GTNWSRP-378
>                 URL: https://issues.jboss.org/browse/GTNWSRP-378
>             Project: GateIn WSRP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Producer
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> See BZ#1115512 . The WSRP Producer WAR seems to be missing the <distributable/> tag on web.xml , causing session replication to not work for communication between consumer and producer. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:44:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Jul 2014 09:44:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-378) WSRP Producer is missing
 distributable tag
In-Reply-To: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546193.1405085989000.56112.1405086265824@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNWSRP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated GTNWSRP-378:
--------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1115512


> WSRP Producer is missing distributable tag
> ------------------------------------------
>
>                 Key: GTNWSRP-378
>                 URL: https://issues.jboss.org/browse/GTNWSRP-378
>             Project: GateIn WSRP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Producer
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> See BZ#1115512 . The WSRP Producer WAR seems to be missing the <distributable/> tag on web.xml , causing session replication to not work for communication between consumer and producer. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:44:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Jul 2014 09:44:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-378) WSRP Producer is missing
 distributable tag
In-Reply-To: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546193.1405085989000.56114.1405086265979@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNWSRP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984238#comment-12984238 ] 

RH Bugzilla Integration commented on GTNWSRP-378:
-------------------------------------------------

Juraci Paixao Krohling <jcosta at redhat.com> changed the Status of [bug 1115512|https://bugzilla.redhat.com/show_bug.cgi?id=1115512] from ASSIGNED to POST

> WSRP Producer is missing distributable tag
> ------------------------------------------
>
>                 Key: GTNWSRP-378
>                 URL: https://issues.jboss.org/browse/GTNWSRP-378
>             Project: GateIn WSRP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Producer
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> See BZ#1115512 . The WSRP Producer WAR seems to be missing the <distributable/> tag on web.xml , causing session replication to not work for communication between consumer and producer. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:46:27 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Fri, 11 Jul 2014 09:46:27 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-378) WSRP Producer is missing
 distributable tag
In-Reply-To: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546193.1405085989000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546193.1405085989000.56121.1405086387525@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNWSRP-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juraci Paix?o Kr?hling updated GTNWSRP-378:
-------------------------------------------

        Status: Resolved  (was: Pull Request Sent)
    Resolution: Done


> WSRP Producer is missing distributable tag
> ------------------------------------------
>
>                 Key: GTNWSRP-378
>                 URL: https://issues.jboss.org/browse/GTNWSRP-378
>             Project: GateIn WSRP
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Producer
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> See BZ#1115512 . The WSRP Producer WAR seems to be missing the <distributable/> tag on web.xml , causing session replication to not work for communication between consumer and producer. 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:54:28 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Fri, 11 Jul 2014 09:54:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3519) "Import applications"
 fails when remote portlet name clashes with local portlet
In-Reply-To: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546150.1405064271000.56178.1405086868150@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Juraci Paix?o Kr?hling updated GTNPORTAL-3519:
----------------------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/887


> "Import applications" fails when remote portlet name clashes with local portlet
> -------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3519
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3519
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> The "import applications" on the application registry fails when there's a remote portlet with the same name as a local portlet, due to "unknown error" on the user interface, and "Cannot create a content with a content id ... with an existing different content id" in the logs. 
> More details on BZ#1117813 . 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:54:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Jul 2014 09:54:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3519) "Import applications"
 fails when remote portlet name clashes with local portlet
In-Reply-To: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546150.1405064271000.56187.1405086868836@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated GTNPORTAL-3519:
-----------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1117813


> "Import applications" fails when remote portlet name clashes with local portlet
> -------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3519
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3519
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> The "import applications" on the application registry fails when there's a remote portlet with the same name as a local portlet, due to "unknown error" on the user interface, and "Cannot create a content with a content id ... with an existing different content id" in the logs. 
> More details on BZ#1117813 . 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Fri Jul 11 09:56:26 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 11 Jul 2014 09:56:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3519) "Import applications"
 fails when remote portlet name clashes with local portlet
In-Reply-To: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546150.1405064271000.56204.1405086986587@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12984246#comment-12984246 ] 

RH Bugzilla Integration commented on GTNPORTAL-3519:
----------------------------------------------------

Juraci Paixao Krohling <jcosta at redhat.com> changed the Status of [bug 1117813|https://bugzilla.redhat.com/show_bug.cgi?id=1117813] from ASSIGNED to POST

> "Import applications" fails when remote portlet name clashes with local portlet
> -------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3519
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3519
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> The "import applications" on the application registry fails when there's a remote portlet with the same name as a local portlet, due to "unknown error" on the user interface, and "Cannot create a content with a content id ... with an existing different content id" in the logs. 
> More details on BZ#1117813 . 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Tue Jul 15 01:12:29 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 15 Jul 2014 01:12:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3520) Potential dupication
 of UI component's id when edit layout
In-Reply-To: <JIRA.12546420.1405401094234@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546420.1405401094234@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546420.1405401094234.3291.1405401149136@jira02.app.mwc.hst.phx2.redhat.com>

Vu Viet Phuong created GTNPORTAL-3520:
-----------------------------------------

             Summary: Potential dupication of UI component's id when edit layout
                 Key: GTNPORTAL-3520
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3520
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.8.2.Final
            Reporter: Vu Viet Phuong
            Assignee: Vu Viet Phuong
             Fix For: 3.7.2.Final


- To reproduce this bug, we need to modify the pre-define portal layout, edit portal.xml (https://github.com/gatein/gatein-portal/blob/3.8.4.Final/web/portal/src/main/webapp/WEB-INF/conf/portal/portal/template/classic/portal.xml)

Add this config to the sitelayout
<container id="TestContainer" template="system:/groovy/portal/webui/container/UIContainer.gtmpl">
  <access-permissions>Everyone</access-permissions>
</container>

--> Start fresh gatein
- Create 2 new portal site "test1", "test2" with template "classic"
- Go to test1 site --> site management page --> edit layout of "test2"
- Edit the "TestContainer" properties, then save
- Now edit "test2" layout again --> now what we have modified on "TestContainer" of "test2" is gone

--> The problem is, there is a duplication of id on 2 site "test1" and "test2"





--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Tue Jul 15 03:08:29 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 15 Jul 2014 03:08:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3520) Potential dupication
 of UI component's id when edit layout
In-Reply-To: <JIRA.12546420.1405401094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546420.1405401094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546420.1405401094000.3436.1405408109912@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vu Viet Phuong resolved GTNPORTAL-3520.
---------------------------------------

    Resolution: Done


> Potential dupication of UI component's id when edit layout
> ----------------------------------------------------------
>
>                 Key: GTNPORTAL-3520
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3520
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.2.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>             Fix For: 3.7.2.Final
>
>
> - To reproduce this bug, we need to modify the pre-define portal layout, edit portal.xml (https://github.com/gatein/gatein-portal/blob/3.8.4.Final/web/portal/src/main/webapp/WEB-INF/conf/portal/portal/template/classic/portal.xml)
> Add this config to the sitelayout
> <container id="TestContainer" template="system:/groovy/portal/webui/container/UIContainer.gtmpl">
>   <access-permissions>Everyone</access-permissions>
> </container>
> --> Start fresh gatein
> - Create 2 new portal site "test1", "test2" with template "classic"
> - Go to test1 site --> site management page --> edit layout of "test2"
> - Edit the "TestContainer" properties, then save
> - Now edit "test2" layout again --> now what we have modified on "TestContainer" of "test2" is gone
> --> The problem is, there is a duplication of id on 2 site "test1" and "test2"



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Tue Jul 15 03:54:29 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 15 Jul 2014 03:54:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3520) Potential dupication
 of UI component's id when edit layout
In-Reply-To: <JIRA.12546420.1405401094000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546420.1405401094000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546420.1405401094000.3577.1405410869140@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vu Viet Phuong updated GTNPORTAL-3520:
--------------------------------------

    Fix Version/s: 3.9.0.Final


> Potential dupication of UI component's id when edit layout
> ----------------------------------------------------------
>
>                 Key: GTNPORTAL-3520
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3520
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.2.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>             Fix For: 3.7.2.Final, 3.9.0.Final
>
>
> - To reproduce this bug, we need to modify the pre-define portal layout, edit portal.xml (https://github.com/gatein/gatein-portal/blob/3.8.4.Final/web/portal/src/main/webapp/WEB-INF/conf/portal/portal/template/classic/portal.xml)
> Add this config to the sitelayout
> <container id="TestContainer" template="system:/groovy/portal/webui/container/UIContainer.gtmpl">
>   <access-permissions>Everyone</access-permissions>
> </container>
> --> Start fresh gatein
> - Create 2 new portal site "test1", "test2" with template "classic"
> - Go to test1 site --> site management page --> edit layout of "test2"
> - Edit the "TestContainer" properties, then save
> - Now edit "test2" layout again --> now what we have modified on "TestContainer" of "test2" is gone
> --> The problem is, there is a duplication of id on 2 site "test1" and "test2"



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Tue Jul 15 10:22:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 15 Jul 2014 10:22:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3506) Allow multiple apps
 registering the very same AMD paths
In-Reply-To: <JIRA.12542915.1401967625000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542915.1401967625000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542915.1401967625000.5152.1405434150892@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12985228#comment-12985228 ] 

RH Bugzilla Integration commented on GTNPORTAL-3506:
----------------------------------------------------

Tomas Kyjovsky <tkyjovsk at redhat.com> changed the Status of [bug 1110406|https://bugzilla.redhat.com/show_bug.cgi?id=1110406] from ON_QA to VERIFIED

> 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)

From issues at jboss.org  Fri Jul 18 04:48:29 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Fri, 18 Jul 2014 04:48:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3521) Use the same title
 for select permission popup window
In-Reply-To: <JIRA.12546816.1405673192129@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546816.1405673192129@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546816.1405673192129.11478.1405673309878@jira02.app.mwc.hst.phx2.redhat.com>

Vu Viet Phuong created GTNPORTAL-3521:
-----------------------------------------

             Summary: Use the same title for select permission popup window
                 Key: GTNPORTAL-3521
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3521
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Internationalization and Localization
    Affects Versions: 3.7.1.Final
            Reporter: Vu Viet Phuong
            Assignee: Vu Viet Phuong
            Priority: Minor
             Fix For: 3.7.2.Final


We use same "Select permission" popup in several place in GateIn. But the popup's title is not consistence. Steps to reproduce:
- Login as "root" --> Site --> Add new Site
- Switch to tab "Permission Setting"
- The permission popup title of Access permision is "Select permission" but the one from Edit permission tab is "Permission selector"



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Fri Jul 18 04:48:30 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Fri, 18 Jul 2014 04:48:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3521) Use the same title
 for select permission popup window
In-Reply-To: <JIRA.12546816.1405673192000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546816.1405673192000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546816.1405673192000.11489.1405673310983@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vu Viet Phuong updated GTNPORTAL-3521:
--------------------------------------

    Description: 
We use same "Select permission" popup in several place in GateIn. But the popup's title is not consistence. Steps to reproduce:
- Login as "root" --> Site --> Add new Site
- Switch to tab "Permission Setting"
- The permission popup title of Access permision is "Select permission" but the one from Edit permission tab is "Permission selector"
--> We should use the same title for all permission popup: "Select permission"

  was:
We use same "Select permission" popup in several place in GateIn. But the popup's title is not consistence. Steps to reproduce:
- Login as "root" --> Site --> Add new Site
- Switch to tab "Permission Setting"
- The permission popup title of Access permision is "Select permission" but the one from Edit permission tab is "Permission selector"



> Use the same title for select permission popup window
> -----------------------------------------------------
>
>                 Key: GTNPORTAL-3521
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3521
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.7.1.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>            Priority: Minor
>             Fix For: 3.7.2.Final
>
>
> We use same "Select permission" popup in several place in GateIn. But the popup's title is not consistence. Steps to reproduce:
> - Login as "root" --> Site --> Add new Site
> - Switch to tab "Permission Setting"
> - The permission popup title of Access permision is "Select permission" but the one from Edit permission tab is "Permission selector"
> --> We should use the same title for all permission popup: "Select permission"



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Fri Jul 18 06:12:29 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Fri, 18 Jul 2014 06:12:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3521) Use the same title
 for select permission popup window
In-Reply-To: <JIRA.12546816.1405673192000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546816.1405673192000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546816.1405673192000.11782.1405678349167@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vu Viet Phuong resolved GTNPORTAL-3521.
---------------------------------------

    Resolution: Done


> Use the same title for select permission popup window
> -----------------------------------------------------
>
>                 Key: GTNPORTAL-3521
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3521
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.7.1.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>            Priority: Minor
>             Fix For: 3.7.2.Final
>
>
> We use same "Select permission" popup in several place in GateIn. But the popup's title is not consistence. Steps to reproduce:
> - Login as "root" --> Site --> Add new Site
> - Switch to tab "Permission Setting"
> - The permission popup title of Access permision is "Select permission" but the one from Edit permission tab is "Permission selector"
> --> We should use the same title for all permission popup: "Select permission"



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Fri Jul 18 06:16:30 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Fri, 18 Jul 2014 06:16:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3521) Use the same title
 for select permission popup window
In-Reply-To: <JIRA.12546816.1405673192000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546816.1405673192000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546816.1405673192000.11783.1405678590961@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vu Viet Phuong updated GTNPORTAL-3521:
--------------------------------------

    Fix Version/s: 3.9.0.Final


> Use the same title for select permission popup window
> -----------------------------------------------------
>
>                 Key: GTNPORTAL-3521
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3521
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.7.1.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>            Priority: Minor
>             Fix For: 3.7.2.Final, 3.9.0.Final
>
>
> We use same "Select permission" popup in several place in GateIn. But the popup's title is not consistence. Steps to reproduce:
> - Login as "root" --> Site --> Add new Site
> - Switch to tab "Permission Setting"
> - The permission popup title of Access permision is "Select permission" but the one from Edit permission tab is "Permission selector"
> --> We should use the same title for all permission popup: "Select permission"



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Tue Jul 22 07:09:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 22 Jul 2014 07:09:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3503) Define a default
 order for page management results
In-Reply-To: <JIRA.12542616.1401787347000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542616.1401787347000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542616.1401787347000.16990.1406027370502@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12986968#comment-12986968 ] 

RH Bugzilla Integration commented on GTNPORTAL-3503:
----------------------------------------------------

Petr Mensik <pmensik at redhat.com> changed the Status of [bug 1102742|https://bugzilla.redhat.com/show_bug.cgi?id=1102742] from ON_QA to VERIFIED

> Define a default order for page management results
> --------------------------------------------------
>
>                 Key: GTNPORTAL-3503
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3503
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> POMSession.findObjects() performs a pages query without a default order.
> This can cause an issue in PageManagement portlet repeating results.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 23 05:37:30 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 23 Jul 2014 05:37:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3522) Failed
 testRemoteGadget when build gatein portal-3.5.x with unstable internet
 connection
In-Reply-To: <JIRA.12547242.1406108243837@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547242.1406108243837@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547242.1406108243837.19792.1406108250273@jira02.app.mwc.hst.phx2.redhat.com>

Tran Trung Thanh created GTNPORTAL-3522:
-------------------------------------------

             Summary: Failed testRemoteGadget when build gatein portal-3.5.x with unstable internet connection
                 Key: GTNPORTAL-3522
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3522
             Project: GateIn Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Tran Trung Thanh


In some cases, when the internet connection is not stable, build failure gatein 3.5
{noformat}
Test set: org.exoplatform.application.gadget.TestGadgetRegistryService
-------------------------------------------------------------------------------
Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 19.27 sec <<< FAILURE!
testRemoteGadget(org.exoplatform.application.gadget.TestGadgetRegistryService)  Time elapsed: 5.102 sec  <<< ERROR!
java.io.IOException
	at org.exoplatform.application.gadget.GadgetImporter.doImport(GadgetImporter.java:93)
	at org.exoplatform.application.gadget.TestGadgetRegistryService$TestGadgetImporter.doImport(TestGadgetRegistryService.java:176)
	at org.exoplatform.application.gadget.TestGadgetRegistryService.testRemoteGadget(TestGadgetRegistryService.java:84)
{noformat}

The problem comes from link http://www.labpixies.com/campaigns/weather/weather.xml in *testRemoteGadget* function of *TestGadgetRegistryService* class, sometime I can't access to this link.

{noformat}
[11:51:23-451][INFO] GadgetImporter Importing gadget name=local_test description=__MSG_description__ thumbnail=http://www.labpixies.com/campaigns/weather/images/thumbnail.jpg title=http://www.labpixies.com/campaigns/weather/images/thumbnail.jpg title=__MSG_gTitle__ 
[11:51:23-475][INFO] TestGadgetRegistryService Unit test testLocalGadget completed 
[11:51:23-479][INFO] TestGadgetRegistryService Running unit test:testRemoteGadget 
[11:51:28-526][SEVERE] GadgetImporter Cannot import gadget http://www.labpixies.com/campaigns/weather/weather.xml because its data could not be found 
[11:51:28-527][SEVERE] TestGadgetRegistryService Unit test testRemoteGadget did not complete java.io.IOException
	at org.exoplatform.application.gadget.GadgetImporter.doImport(GadgetImporter.java:93)
	at org.exoplatform.application.gadget.TestGadgetRegistryService$TestGadgetImporter.doImport(TestGadgetRegistryService.java:176)
	at org.exoplatform.application.gadget.TestGadgetRegistryService.testRemoteGadget(TestGadgetRegistryService.java:84)
{noformat} 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 23 05:41:30 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 23 Jul 2014 05:41:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3522) Failed
 testRemoteGadget when build gatein portal-3.5.x with unstable internet
 connection
In-Reply-To: <JIRA.12547242.1406108243000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547242.1406108243000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547242.1406108243000.19798.1406108490317@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tran Trung Thanh updated GTNPORTAL-3522:
----------------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/889


> Failed testRemoteGadget when build gatein portal-3.5.x with unstable internet connection
> ----------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3522
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3522
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Tran Trung Thanh
>
> In some cases, when the internet connection is not stable, build failure gatein 3.5
> {noformat}
> Test set: org.exoplatform.application.gadget.TestGadgetRegistryService
> -------------------------------------------------------------------------------
> Tests run: 2, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 19.27 sec <<< FAILURE!
> testRemoteGadget(org.exoplatform.application.gadget.TestGadgetRegistryService)  Time elapsed: 5.102 sec  <<< ERROR!
> java.io.IOException
> 	at org.exoplatform.application.gadget.GadgetImporter.doImport(GadgetImporter.java:93)
> 	at org.exoplatform.application.gadget.TestGadgetRegistryService$TestGadgetImporter.doImport(TestGadgetRegistryService.java:176)
> 	at org.exoplatform.application.gadget.TestGadgetRegistryService.testRemoteGadget(TestGadgetRegistryService.java:84)
> {noformat}
> The problem comes from link http://www.labpixies.com/campaigns/weather/weather.xml in *testRemoteGadget* function of *TestGadgetRegistryService* class, sometime I can't access to this link.
> {noformat}
> [11:51:23-451][INFO] GadgetImporter Importing gadget name=local_test description=__MSG_description__ thumbnail=http://www.labpixies.com/campaigns/weather/images/thumbnail.jpg title=http://www.labpixies.com/campaigns/weather/images/thumbnail.jpg title=__MSG_gTitle__ 
> [11:51:23-475][INFO] TestGadgetRegistryService Unit test testLocalGadget completed 
> [11:51:23-479][INFO] TestGadgetRegistryService Running unit test:testRemoteGadget 
> [11:51:28-526][SEVERE] GadgetImporter Cannot import gadget http://www.labpixies.com/campaigns/weather/weather.xml because its data could not be found 
> [11:51:28-527][SEVERE] TestGadgetRegistryService Unit test testRemoteGadget did not complete java.io.IOException
> 	at org.exoplatform.application.gadget.GadgetImporter.doImport(GadgetImporter.java:93)
> 	at org.exoplatform.application.gadget.TestGadgetRegistryService$TestGadgetImporter.doImport(TestGadgetRegistryService.java:176)
> 	at org.exoplatform.application.gadget.TestGadgetRegistryService.testRemoteGadget(TestGadgetRegistryService.java:84)
> {noformat} 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 23 06:45:30 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Wed, 23 Jul 2014 06:45:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3341) Cannot delete users
 with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"
In-Reply-To: <JIRA.12527351.1386602095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527351.1386602095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527351.1386602095000.19923.1406112330246@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987370#comment-12987370 ] 

Tran Trung Thanh commented on GTNPORTAL-3341:
---------------------------------------------

PR for gatein 3.5.x: https://github.com/gatein/gatein-portal/pull/890
I only backport partial fix from Gatein 3.6 which avoids using empty string

> Cannot delete users with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"
> -----------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3341
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3341
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.6.3.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.6.4.Final, 3.7.0.Final
>
>
> Description of problem:
> Cannot delete users with OracleDB (reproducible at least on version 11gR2) because of "ORA-02292: integrity constraint (XXXXX) violated - child record found"[1]. The child record is in the JBID_IO_ATTR table[2].
> [1]
> 2013-12-05 15:40:25,846 DEBUG [org.hibernate.util.JDBCExceptionReporter] (http-127.0.0.1-8080-1) Could not execute JDBC batch update [delete from jbid_io where ID=?]
> java.sql.BatchUpdateException: ORA-02292: integrity constraint (ORAUSER.FK4DC61D7E992317F0) violated - child record found
>     at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10345)
>     at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:230)
>     at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:476)
>     at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774)
>     at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
>     at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
>     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
>     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:171)
>     at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
>     at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
>     at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1030)
>     at sun.reflect.GeneratedMethodAccessor346.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:343)
>     at com.sun.proxy.$Proxy266.flush(Unknown Source)
>     at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:622)
>     at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.removeIdentityObject(WrapperIdentityStoreRepository.java:158)
>     at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.removeUser(PersistenceManagerImpl.java:231)
>     at org.exoplatform.services.organization.idm.UserDAOImpl.removeUser(UserDAOImpl.java:268)
> [2]
> JBID_IO_ATTR:
> ATTRIBUTE_ID	423
> IDENTITY_OBJECT_ID	413
> NAME	user.language
> ATTRIBUTE_TYPE	text
> BIN_VALUE_ID	NULL
> How reproducible: 100 %
> Steps to Reproduce:
> 1. Change gatein-idm and gatein-jcr to use OracleDB.
> 2. Start EPP
> 3. Login as root
> 4. Create a user
> 5. Delete the user
> Actual results:
> Cannot delete the user. 
> Expected results:
> The user is deleted.
> Additional info:
> Some user attributes are deleted, so this process is not transactional.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 23 11:27:29 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 23 Jul 2014 11:27:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3518) Use a variable to
	enable the sequence
In-Reply-To: <JIRA.12546048.1404996658000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546048.1404996658000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546048.1404996658000.20537.1406129249642@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga resolved GTNPORTAL-3518.
-------------------------------------

    Resolution: Done


> Use a variable to enable the sequence
> -------------------------------------
>
>                 Key: GTNPORTAL-3518
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3518
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: JCR integration
>    Affects Versions: 3.8.2.Final
>            Reporter: Nicolas Filotto
>             Fix For: 3.8.5.Final, 3.9.0.Final
>
>
> Starting from eXo JCR 1.16.0 Alpha4, we have an improvement (aka https://jira.exoplatform.org/browse/JCR-2262) that allows to provide a better scalability in term of total amount of sub nodes that a node can have without affecting the performances, indeed with big tables the performances get worse especially when we have a node with a lot of sub nodes so to push the scalability limit, eXo JCR can now rely on sequences. 
> The sequences can be enabled thanks to a new parameter in the data container configuration of the workspace called {{use-sequence-for-order-number}}, by default it is set to {{auto}} so it will be enabled on all the databases on which we know that the sequences help to improve the performances and the scalability such as on Oracle and PostgreSQL, but also on H2 and HSQLDB.
> Unfortunately, this improvement causes a regression which is (https://jira.exoplatform.org/browse/JCR-2322), so as workaround we can configure this parameter using a variable with {{false}} as default value, this way once the bug will be fixed, we will be able to set it back to the default value which is {{auto}}.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 23 11:31:31 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 23 Jul 2014 11:31:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3519) "Import applications"
 fails when remote portlet name clashes with local portlet
In-Reply-To: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546150.1405064271000.20550.1406129491156@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga updated GTNPORTAL-3519:
------------------------------------

           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 3.8.5.Final
                   3.9.0.Final
       Resolution: Done


> "Import applications" fails when remote portlet name clashes with local portlet
> -------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3519
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3519
>             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.5.Final, 3.9.0.Final
>
>
> The "import applications" on the application registry fails when there's a remote portlet with the same name as a local portlet, due to "unknown error" on the user interface, and "Cannot create a content with a content id ... with an existing different content id" in the logs. 
> More details on BZ#1117813 . 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Wed Jul 23 11:31:31 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 23 Jul 2014 11:31:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3519) "Import applications"
 fails when remote portlet name clashes with local portlet
In-Reply-To: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12546150.1405064271000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546150.1405064271000.20556.1406129491722@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987447#comment-12987447 ] 

RH Bugzilla Integration commented on GTNPORTAL-3519:
----------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1117813|https://bugzilla.redhat.com/show_bug.cgi?id=1117813] from POST to MODIFIED

> "Import applications" fails when remote portlet name clashes with local portlet
> -------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3519
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3519
>             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.5.Final, 3.9.0.Final
>
>
> The "import applications" on the application registry fails when there's a remote portlet with the same name as a local portlet, due to "unknown error" on the user interface, and "Cannot create a content with a content id ... with an existing different content id" in the logs. 
> More details on BZ#1117813 . 



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Thu Jul 24 03:35:30 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 24 Jul 2014 03:35:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3341) Cannot delete users
 with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"
In-Reply-To: <JIRA.12527351.1386602095000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12527351.1386602095000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12527351.1386602095000.21314.1406187330694@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trong Tran updated GTNPORTAL-3341:
----------------------------------

    Fix Version/s: 3.5.11.Final


> Cannot delete users with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"
> -----------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3341
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3341
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.6.3.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.5.11.Final, 3.6.4.Final, 3.7.0.Final
>
>
> Description of problem:
> Cannot delete users with OracleDB (reproducible at least on version 11gR2) because of "ORA-02292: integrity constraint (XXXXX) violated - child record found"[1]. The child record is in the JBID_IO_ATTR table[2].
> [1]
> 2013-12-05 15:40:25,846 DEBUG [org.hibernate.util.JDBCExceptionReporter] (http-127.0.0.1-8080-1) Could not execute JDBC batch update [delete from jbid_io where ID=?]
> java.sql.BatchUpdateException: ORA-02292: integrity constraint (ORAUSER.FK4DC61D7E992317F0) violated - child record found
>     at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10345)
>     at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:230)
>     at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:476)
>     at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774)
>     at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70)
>     at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268)
>     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265)
>     at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:171)
>     at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
>     at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
>     at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1030)
>     at sun.reflect.GeneratedMethodAccessor346.invoke(Unknown Source)
>     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>     at java.lang.reflect.Method.invoke(Method.java:597)
>     at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:343)
>     at com.sun.proxy.$Proxy266.flush(Unknown Source)
>     at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:622)
>     at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.removeIdentityObject(WrapperIdentityStoreRepository.java:158)
>     at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.removeUser(PersistenceManagerImpl.java:231)
>     at org.exoplatform.services.organization.idm.UserDAOImpl.removeUser(UserDAOImpl.java:268)
> [2]
> JBID_IO_ATTR:
> ATTRIBUTE_ID	423
> IDENTITY_OBJECT_ID	413
> NAME	user.language
> ATTRIBUTE_TYPE	text
> BIN_VALUE_ID	NULL
> How reproducible: 100 %
> Steps to Reproduce:
> 1. Change gatein-idm and gatein-jcr to use OracleDB.
> 2. Start EPP
> 3. Login as root
> 4. Create a user
> 5. Delete the user
> Actual results:
> Cannot delete the user. 
> Expected results:
> The user is deleted.
> Additional info:
> Some user attributes are deleted, so this process is not transactional.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 24 03:35:31 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 24 Jul 2014 03:35:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-2103) Can't delete an user
 with Oracle database
In-Reply-To: <JIRA.12447153.1316142218000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12447153.1316142218000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447153.1316142218000.21319.1406187331289@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-2103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trong Tran resolved GTNPORTAL-2103.
-----------------------------------

    Resolution: Duplicate Issue


> Can't delete an user with Oracle database
> -----------------------------------------
>
>                 Key: GTNPORTAL-2103
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-2103
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.2.0-M01
>         Environment: oracle-xe_10.2.0.1-1.0, GateIn revision 7347
>            Reporter: kien nguyen
>            Assignee: Boleslaw Dawidowicz
>         Attachments: gatein2011-09-16.log
>
>
> If an Oracle database is used, we can not delete an user with the organization portlet.
> How to reproduced:
>     * connect to root/gtn.
>     * add new user.
>     * try to delete an user (has just been created) with the organization portlet-> exception
>       See error in log file



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 24 03:57:29 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 24 Jul 2014 03:57:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3523) Default value of
 property "jboss.as.management.blocking.timeout" (300 s) may be insufficient
 for portal startup with more data
In-Reply-To: <JIRA.12547337.1406188563459@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547337.1406188563459@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547337.1406188563459.21348.1406188649195@jira02.app.mwc.hst.phx2.redhat.com>

Peter Palaga created GTNPORTAL-3523:
---------------------------------------

             Summary: Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data
                 Key: GTNPORTAL-3523
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3523
             Project: GateIn Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
          Components: Packaging
    Affects Versions: 3.8.4.Final
            Reporter: Peter Palaga
            Assignee: Peter Palaga
             Fix For: 3.8.5.Final, 3.9.0.Final


Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1117945

In EAP 6.3.0.ER8 (present in JBoss Portal 6.2.0.ER4) there is new class in jboss.as.controller: BlockingTimeout.

This class loads value of system property "jboss.as.management.blocking.timeout" or defaults to 300 (seconds).

This will cause a problem during portal startup if for any reason (more data, slower db) it takes more than 5 minutes.

How reproducible:
with more data (e.g. with >1000 users)


Steps to Reproduce:
1. create a circumstance where portal startup takes longer than 5 minutes
2. start portal

Actual results:
ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
("core-service" => "management"),
("management-interface" => "native-interface")
]'

After that the container is shut down.


Expected results:
Portal has enough time to start up.



Additional info:
The value of "jboss.as.management.blocking.timeout" property can be set to higher value. This should be either documented as workaround or it should be increased in portal configuration.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 24 03:59:29 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 24 Jul 2014 03:59:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3523) Default value of
 property "jboss.as.management.blocking.timeout" (300 s) may be insufficient
 for portal startup with more data
In-Reply-To: <JIRA.12547337.1406188563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547337.1406188563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547337.1406188563000.21352.1406188769810@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987569#comment-12987569 ] 

Peter Palaga commented on GTNPORTAL-3523:
-----------------------------------------

Fixed in master https://github.com/gatein/gatein-portal/commit/78b37121ebf9c89f4fa696387dd79fd4038420de
and 3.8.x https://github.com/gatein/gatein-portal/commit/78b37121ebf9c89f4fa696387dd79fd4038420de

> Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3523
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3523
>             Project: GateIn Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Packaging
>    Affects Versions: 3.8.4.Final
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.5.Final, 3.9.0.Final
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1117945
> In EAP 6.3.0.ER8 (present in JBoss Portal 6.2.0.ER4) there is new class in jboss.as.controller: BlockingTimeout.
> This class loads value of system property "jboss.as.management.blocking.timeout" or defaults to 300 (seconds).
> This will cause a problem during portal startup if for any reason (more data, slower db) it takes more than 5 minutes.
> How reproducible:
> with more data (e.g. with >1000 users)
> Steps to Reproduce:
> 1. create a circumstance where portal startup takes longer than 5 minutes
> 2. start portal
> Actual results:
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
> ("core-service" => "management"),
> ("management-interface" => "native-interface")
> ]'
> After that the container is shut down.
> Expected results:
> Portal has enough time to start up.
> Additional info:
> The value of "jboss.as.management.blocking.timeout" property can be set to higher value. This should be either documented as workaround or it should be increased in portal configuration.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 24 04:01:31 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 24 Jul 2014 04:01:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3523) Default value of
 property "jboss.as.management.blocking.timeout" (300 s) may be insufficient
 for portal startup with more data
In-Reply-To: <JIRA.12547337.1406188563000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547337.1406188563000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547337.1406188563000.21354.1406188891426@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated GTNPORTAL-3523:
-----------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1117945


> Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3523
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3523
>             Project: GateIn Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Packaging
>    Affects Versions: 3.8.4.Final
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.5.Final, 3.9.0.Final
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1117945
> In EAP 6.3.0.ER8 (present in JBoss Portal 6.2.0.ER4) there is new class in jboss.as.controller: BlockingTimeout.
> This class loads value of system property "jboss.as.management.blocking.timeout" or defaults to 300 (seconds).
> This will cause a problem during portal startup if for any reason (more data, slower db) it takes more than 5 minutes.
> How reproducible:
> with more data (e.g. with >1000 users)
> Steps to Reproduce:
> 1. create a circumstance where portal startup takes longer than 5 minutes
> 2. start portal
> Actual results:
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[
> ("core-service" => "management"),
> ("management-interface" => "native-interface")
> ]'
> After that the container is shut down.
> Expected results:
> Portal has enough time to start up.
> Additional info:
> The value of "jboss.as.management.blocking.timeout" property can be set to higher value. This should be either documented as workaround or it should be increased in portal configuration.



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 24 04:21:30 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Thu, 24 Jul 2014 04:21:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot
 use remote portlets
In-Reply-To: <JIRA.12547342.1406189982394@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547342.1406189982394@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547342.1406189982394.21413.1406190090415@jira02.app.mwc.hst.phx2.redhat.com>

Juraci Paix?o Kr?hling created GTNPORTAL-3524:
-------------------------------------------------

             Summary: Custom portals cannot use remote portlets
                 Key: GTNPORTAL-3524
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3524
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: WSRP integration
            Reporter: Juraci Paix?o Kr?hling
            Assignee: Juraci Paix?o Kr?hling


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.2.6#6264)


From issues at jboss.org  Thu Jul 24 04:25:31 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Thu, 24 Jul 2014 04:25:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot
 use remote portlets
In-Reply-To: <JIRA.12547342.1406189982000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547342.1406189982000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547342.1406189982000.21431.1406190331203@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987580#comment-12987580 ] 

Juraci Paix?o Kr?hling commented on GTNPORTAL-3524:
---------------------------------------------------

I'm still working on getting a proper fix for this, but in the meantime, I'll make the quick workarounds available: 

First workaround - add a configuration option to specify on which portal to bind the consumers to. The option is {code}gatein.wsrp.consumer.bindToPortalName{code} and should be added to {code}standalone/configuration/gatein/configuration.properties{code}. Branch for this workaround: 
https://github.com/jpkrohling/gatein-portal/tree/BZ1122527-ConsumerOnCustomPortalCannotFindWSRP-ConfigOption

> Custom portals cannot use remote portlets
> -----------------------------------------
>
>                 Key: GTNPORTAL-3524
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3524
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: WSRP integration
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> 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.2.6#6264)


From issues at jboss.org  Thu Jul 24 05:55:31 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Thu, 24 Jul 2014 05:55:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot
 use remote portlets
In-Reply-To: <JIRA.12547342.1406189982000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547342.1406189982000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547342.1406189982000.21716.1406195731040@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12987617#comment-12987617 ] 

Juraci Paix?o Kr?hling commented on GTNPORTAL-3524:
---------------------------------------------------

I've just submitted another set of branches for a more permanent solution. Note that this needs to be verified and validated by QE, but would be interesting to get the customer's feedback as well (after QE runs at least a smoke test). 

Branches:
https://github.com/jpkrohling/gatein-portal/tree/BZ1122527-ConsumerOnCustomPortalCannotFindWSRP
https://github.com/jpkrohling/gatein-wsrp/tree/BZ1122527-ConsumerOnCustomPortalCannotFindWSRP

> Custom portals cannot use remote portlets
> -----------------------------------------
>
>                 Key: GTNPORTAL-3524
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3524
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: WSRP integration
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> 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.2.6#6264)


From issues at jboss.org  Mon Jul 28 10:11:31 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 28 Jul 2014 10:11:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3525) JTA -
 HibernateException: Unable to locate current JTA transaction
In-Reply-To: <JIRA.12547616.1406556636024@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547616.1406556636024@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547616.1406556636024.28121.1406556691599@jira02.app.mwc.hst.phx2.redhat.com>

Marek Posolda created GTNPORTAL-3525:
----------------------------------------

             Summary: JTA - HibernateException: Unable to locate current JTA transaction
                 Key: GTNPORTAL-3525
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3525
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.8.2.Final
            Reporter: Marek Posolda
            Assignee: Marek Posolda
             Fix For: 3.8.3.Final, 3.9.0.Final


See https://bugzilla.redhat.com/show_bug.cgi?id=1122138 . Snipet from tacktrace:
{code}
08:24:01,660 INFO  [org.exoplatform.services.organization.idm.UserDAOImpl] (http-vmg39.mw.lab.eng.bos.redhat.com/10.16.88.117:8080-5) Cannot obtain user: john; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2798) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2850) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObject(HibernateIdentityStoreImpl.java:2896) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.safeGet(HibernateIdentityStoreImpl.java:2821) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:684) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:171) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.exoplatform.services.organization.idm.UserDAOImpl.getPopulatedUser(UserDAOImpl.java:727) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
	at org.exoplatform.services.organization.idm.UserDAOImpl.findUserByName(UserDAOImpl.java:294) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
	at org.exoplatform.web.login.FilterDisabledLoginModule.login(FilterDisabledLoginModule.java:72) [exo.portal.component.web.security-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
...
Caused by: org.hibernate.HibernateException: Unable to locate current JTA transaction
	at org.hibernate.context.internal.JTASessionContext.currentSession(JTASessionContext.java:89)
	at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:993)
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.getSessionContext(HibernateIdentityStoreSessionImpl.java:57) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2789) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
	... 89 more
{code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Mon Jul 28 10:11:32 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Jul 2014 10:11:32 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3525) JTA -
 HibernateException: Unable to locate current JTA transaction
In-Reply-To: <JIRA.12547616.1406556636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547616.1406556636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547616.1406556636000.28129.1406556692823@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated GTNPORTAL-3525:
-----------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1122138


> JTA - HibernateException: Unable to locate current JTA transaction
> ------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3525
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3525
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1122138 . Snipet from tacktrace:
> {code}
> 08:24:01,660 INFO  [org.exoplatform.services.organization.idm.UserDAOImpl] (http-vmg39.mw.lab.eng.bos.redhat.com/10.16.88.117:8080-5) Cannot obtain user: john; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2798) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2850) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObject(HibernateIdentityStoreImpl.java:2896) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.safeGet(HibernateIdentityStoreImpl.java:2821) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:684) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:171) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.exoplatform.services.organization.idm.UserDAOImpl.getPopulatedUser(UserDAOImpl.java:727) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> 	at org.exoplatform.services.organization.idm.UserDAOImpl.findUserByName(UserDAOImpl.java:294) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> 	at org.exoplatform.web.login.FilterDisabledLoginModule.login(FilterDisabledLoginModule.java:72) [exo.portal.component.web.security-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> ...
> Caused by: org.hibernate.HibernateException: Unable to locate current JTA transaction
> 	at org.hibernate.context.internal.JTASessionContext.currentSession(JTASessionContext.java:89)
> 	at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:993)
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.getSessionContext(HibernateIdentityStoreSessionImpl.java:57) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2789) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	... 89 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Mon Jul 28 10:15:38 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 28 Jul 2014 10:15:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3525) JTA -
 HibernateException: Unable to locate current JTA transaction
In-Reply-To: <JIRA.12547616.1406556636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547616.1406556636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547616.1406556636000.28171.1406556938515@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Posolda updated GTNPORTAL-3525:
-------------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/892


There was issue in FilterDisabledLoginModule (missing begin/end RequestLifecycle call for OrganizationService) which is causing this.

> JTA - HibernateException: Unable to locate current JTA transaction
> ------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3525
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3525
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1122138 . Snipet from tacktrace:
> {code}
> 08:24:01,660 INFO  [org.exoplatform.services.organization.idm.UserDAOImpl] (http-vmg39.mw.lab.eng.bos.redhat.com/10.16.88.117:8080-5) Cannot obtain user: john; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2798) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2850) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObject(HibernateIdentityStoreImpl.java:2896) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.safeGet(HibernateIdentityStoreImpl.java:2821) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:684) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:171) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.exoplatform.services.organization.idm.UserDAOImpl.getPopulatedUser(UserDAOImpl.java:727) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> 	at org.exoplatform.services.organization.idm.UserDAOImpl.findUserByName(UserDAOImpl.java:294) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> 	at org.exoplatform.web.login.FilterDisabledLoginModule.login(FilterDisabledLoginModule.java:72) [exo.portal.component.web.security-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> ...
> Caused by: org.hibernate.HibernateException: Unable to locate current JTA transaction
> 	at org.hibernate.context.internal.JTASessionContext.currentSession(JTASessionContext.java:89)
> 	at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:993)
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.getSessionContext(HibernateIdentityStoreSessionImpl.java:57) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2789) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	... 89 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Mon Jul 28 10:19:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 28 Jul 2014 10:19:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3525) JTA -
 HibernateException: Unable to locate current JTA transaction
In-Reply-To: <JIRA.12547616.1406556636000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547616.1406556636000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547616.1406556636000.28187.1406557169453@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12988325#comment-12988325 ] 

RH Bugzilla Integration commented on GTNPORTAL-3525:
----------------------------------------------------

mposolda at redhat.com changed the Status of [bug 1122138|https://bugzilla.redhat.com/show_bug.cgi?id=1122138] from ASSIGNED to POST

> JTA - HibernateException: Unable to locate current JTA transaction
> ------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3525
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3525
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> See https://bugzilla.redhat.com/show_bug.cgi?id=1122138 . Snipet from tacktrace:
> {code}
> 08:24:01,660 INFO  [org.exoplatform.services.organization.idm.UserDAOImpl] (http-vmg39.mw.lab.eng.bos.redhat.com/10.16.88.117:8080-5) Cannot obtain user: john; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2798) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2850) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObject(HibernateIdentityStoreImpl.java:2896) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.safeGet(HibernateIdentityStoreImpl.java:2821) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:684) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:171) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.exoplatform.services.organization.idm.UserDAOImpl.getPopulatedUser(UserDAOImpl.java:727) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> 	at org.exoplatform.services.organization.idm.UserDAOImpl.findUserByName(UserDAOImpl.java:294) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> 	at org.exoplatform.web.login.FilterDisabledLoginModule.login(FilterDisabledLoginModule.java:72) [exo.portal.component.web.security-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1]
> ...
> Caused by: org.hibernate.HibernateException: Unable to locate current JTA transaction
> 	at org.hibernate.context.internal.JTASessionContext.currentSession(JTASessionContext.java:89)
> 	at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:993)
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.getSessionContext(HibernateIdentityStoreSessionImpl.java:57) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2789) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1]
> 	... 89 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)


From issues at jboss.org  Wed Jul 30 04:54:29 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Wed, 30 Jul 2014 04:54:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3526) Upgrade to use JCR
	1.16.1-GA
In-Reply-To: <JIRA.12547835.1406710412270@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547835.1406710412270@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547835.1406710412270.32173.1406710469867@jira02.app.mwc.hst.phx2.redhat.com>

Trong Tran created GTNPORTAL-3526:
-------------------------------------

             Summary: Upgrade to use JCR 1.16.1-GA
                 Key: GTNPORTAL-3526
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3526
             Project: GateIn Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Trong Tran






--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 30 04:54:30 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Wed, 30 Jul 2014 04:54:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3526) Upgrade to use JCR
	1.16.1-GA
In-Reply-To: <JIRA.12547835.1406710412000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547835.1406710412000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547835.1406710412000.32175.1406710470000@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trong Tran updated GTNPORTAL-3526:
----------------------------------

    Fix Version/s: 3.9.0.Final


> Upgrade to use JCR 1.16.1-GA
> ----------------------------
>
>                 Key: GTNPORTAL-3526
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3526
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Trong Tran
>             Fix For: 3.9.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 30 11:20:30 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 30 Jul 2014 11:20:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3527) Node.displayNames
 contains #{key} in rest API
In-Reply-To: <JIRA.12547948.1406733541200@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547948.1406733541200@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547948.1406733541200.34009.1406733630812@jira02.app.mwc.hst.phx2.redhat.com>

Peter Palaga created GTNPORTAL-3527:
---------------------------------------

             Summary: Node.displayNames contains #{key} in rest API
                 Key: GTNPORTAL-3527
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3527
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: REST API
            Reporter: Peter Palaga
            Assignee: Peter Palaga


Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1122488

When node of existing space navigation is accessed, list of display names have wrong value - variable instead of the value.
e.g.:
link: http://localhost:8080/rest/private/managed-components/api/spaces/platform/administrators/navigation/administration

"displayNames" : [{"value" : "#{administration.title}"}]



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 30 11:26:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Jul 2014 11:26:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3527) Node.displayNames
 contains #{key} in rest API
In-Reply-To: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547948.1406733541000.34055.1406733989976@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

RH Bugzilla Integration updated GTNPORTAL-3527:
-----------------------------------------------

        Bugzilla Update: Perform
    Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1122488


> Node.displayNames contains #{key} in rest API
> ---------------------------------------------
>
>                 Key: GTNPORTAL-3527
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3527
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST API
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1122488
> When node of existing space navigation is accessed, list of display names have wrong value - variable instead of the value.
> e.g.:
> link: http://localhost:8080/rest/private/managed-components/api/spaces/platform/administrators/navigation/administration
> "displayNames" : [{"value" : "#{administration.title}"}]



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 30 11:26:30 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 30 Jul 2014 11:26:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3527) Node.displayNames
 contains #{key} in rest API
In-Reply-To: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547948.1406733541000.34061.1406733990547@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga updated GTNPORTAL-3527:
------------------------------------

              Status: Pull Request Sent  (was: Open)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/893


> Node.displayNames contains #{key} in rest API
> ---------------------------------------------
>
>                 Key: GTNPORTAL-3527
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3527
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST API
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1122488
> When node of existing space navigation is accessed, list of display names have wrong value - variable instead of the value.
> e.g.:
> link: http://localhost:8080/rest/private/managed-components/api/spaces/platform/administrators/navigation/administration
> "displayNames" : [{"value" : "#{administration.title}"}]



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Wed Jul 30 11:28:30 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 30 Jul 2014 11:28:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3527) Node.displayNames
 contains #{key} in rest API
In-Reply-To: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547948.1406733541000.34066.1406734110297@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989178#comment-12989178 ] 

RH Bugzilla Integration commented on GTNPORTAL-3527:
----------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1122488|https://bugzilla.redhat.com/show_bug.cgi?id=1122488] from ASSIGNED to POST

> Node.displayNames contains #{key} in rest API
> ---------------------------------------------
>
>                 Key: GTNPORTAL-3527
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3527
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST API
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1122488
> When node of existing space navigation is accessed, list of display names have wrong value - variable instead of the value.
> e.g.:
> link: http://localhost:8080/rest/private/managed-components/api/spaces/platform/administrators/navigation/administration
> "displayNames" : [{"value" : "#{administration.title}"}]



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 31 07:48:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 31 Jul 2014 07:48:29 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3527) Node.displayNames
 contains #{key} in rest API
In-Reply-To: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547948.1406733541000.35931.1406807309205@jira02.app.mwc.hst.phx2.redhat.com>


    [ https://issues.jboss.org/browse/GTNPORTAL-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989454#comment-12989454 ] 

RH Bugzilla Integration commented on GTNPORTAL-3527:
----------------------------------------------------

Peter Palaga <ppalaga at redhat.com> changed the Status of [bug 1122488|https://bugzilla.redhat.com/show_bug.cgi?id=1122488] from POST to CLOSED

> Node.displayNames contains #{key} in rest API
> ---------------------------------------------
>
>                 Key: GTNPORTAL-3527
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3527
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST API
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1122488
> When node of existing space navigation is accessed, list of display names have wrong value - variable instead of the value.
> e.g.:
> link: http://localhost:8080/rest/private/managed-components/api/spaces/platform/administrators/navigation/administration
> "displayNames" : [{"value" : "#{administration.title}"}]



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)

From issues at jboss.org  Thu Jul 31 09:18:30 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 31 Jul 2014 09:18:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3527) Node.displayNames
 contains #{key} in rest API
In-Reply-To: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12547948.1406733541000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12547948.1406733541000.36162.1406812710708@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Palaga updated GTNPORTAL-3527:
------------------------------------

           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 3.9.0.Final
       Resolution: Done


> Node.displayNames contains #{key} in rest API
> ---------------------------------------------
>
>                 Key: GTNPORTAL-3527
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3527
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: REST API
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.9.0.Final
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1122488
> When node of existing space navigation is accessed, list of display names have wrong value - variable instead of the value.
> e.g.:
> link: http://localhost:8080/rest/private/managed-components/api/spaces/platform/administrators/navigation/administration
> "displayNames" : [{"value" : "#{administration.title}"}]



--
This message was sent by Atlassian JIRA
(v6.2.6#6264)