From issues at jboss.org  Mon Jun  2 03:37:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 03:37:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-21) Serialization of
 ParameterMap breaks with JBoss Marshalling
In-Reply-To: <JIRA.12530365.1390813730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530365.1390813730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530365.1390813730000.8113.1401694636075@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on GTNCOMMON-21:
--------------------------------------------------

Boleslaw Dawidowicz <bdawidow at redhat.com> changed the Status of [bug 1058216|https://bugzilla.redhat.com/show_bug.cgi?id=1058216] from ASSIGNED to MODIFIED

> Serialization of ParameterMap breaks with JBoss Marshalling
> -----------------------------------------------------------
>
>                 Key: GTNCOMMON-21
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-21
>             Project: GateIn Common
>          Issue Type: Bug
>    Affects Versions: 2.1.1.Final
>         Environment: JPP 6.1.0
>            Reporter: Martin Weiler
>             Fix For: 2.2.0.Beta01, 2.1.2.Final
>
>
> Serialization of a ParameterMap instance with JBoss Marshalling (used by Infinispan) breaks with the following exception:
> {noformat}
> 15:20:33,853 ERROR [org.infinispan.marshall.VersionAwareMarshaller] (transport-thread-11) ISPN000065: Exception while marshalling object: java.io.NotActiveException: Fields were never written
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.finish(RiverObjectOutputStream.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1009)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.clustering.SimpleMarshalledValue.getBytes(SimpleMarshalledValue.java:85)
> 	at org.jboss.as.clustering.SimpleMarshalledValue.writeExternal(SimpleMarshalledValue.java:175)
> 	at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:47)
> 	at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:36)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ForeignExternalizerAdapter.writeObject(ExternalizerTable.java:459)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallMap(MarshallUtil.java:59)
> 	at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:63)
> 	at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:47)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:250)
> 	at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:247)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:154)
> 	at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:150)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:103)
> 	at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:88)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeCommandParameters(ReplicableCommandExternalizer.java:87)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.marshallParameters(CacheRpcCommandExternalizer.java:128)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:112)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:73)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:96)
> 	at org.infinispan.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:92)
> 	at org.infinispan.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:64)
> 	at org.infinispan.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:109)
> 	at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:45)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:279)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:300)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
> 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190)
> 	at org.infinispan.statetransfer.OutboundTransferTask.sendEntries(OutboundTransferTask.java:257)
> 	at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:187)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: an exception which occurred:
> 	in field parameters
> 	in field navigationalState
> 	in object java.util.HashMap at 7b2c68fe
> {noformat}
> The NotActiveException is a result of a broken writeObject implementation in org.gatein.common.util.ParameterMap, which does not call out.defaultWriteObject();



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 04:15:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 04:15:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3498) Errors on
	TestSocialNetworkService
In-Reply-To: <JIRA.12542132.1401276072000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542132.1401276072000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542132.1401276072000.8148.1401696916696@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3498:
------------------------------------

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


> Errors on TestSocialNetworkService
> ----------------------------------
>
>                 Key: GTNPORTAL-3498
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3498
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>         Attachments: org.gatein.security.oauth.test.TestSocialNetworkService.txt
>
>
> Due GTNPORTAL-3365 some tests gets some unexpected exceptions.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 06:03:16 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 2 Jun 2014 06:03:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3493) Membership just added,
	disappears
In-Reply-To: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541890.1401114872000.8459.1401703396289@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda commented on GTNPORTAL-3493:
------------------------------------------

The comment is correct as it is. Parameter "ignoreMappedMembershipTypeGroupList" should be really used just for RW LDAP and it should have just groups, which are mapped to LDAP. 

In MembershipDAOImpl.linkMemberships there are 2 important method calls to IDM:
- getIdentitySession().getRelationshipManager().associateUserByKeys(groupId, user.getUserName()); which is usable for RW LDAP scenario to create the memberships in LDAP. It's only useful when these conditions are met:
- You want to create membership with membershipType "member"
- You have target group mapped as LDAP group
- You have RW LDAP (not read-only LDAP, because in read-only LDAP you want your memberships to be stored in DB and not in LDAP)

- getIdentitySession().getRoleManager().createRole(mt.getName(), user.getUserName(), groupId); -- this is used to create membership in database.

Parameter "ignoreMappedMembershipTypeGroupList" is useful just for RW ldap scenario, because if you have RW LDAP and you won't use "ignoreMappedMembershipTypeGroupList" parameter, then GateIn will invoke both methods mentioned above and create membership in both LDAP server and DB, which would mean that membership will be created 2 times.


In your unit test, you are using Read-Only LDAP, so you shouldn't map anything to  "ignoreMappedMembershipTypeGroupList" and keep it empty. Instead you are mapping it to "/*" which is incorrect (Note that even if you use RW LDAP, you should map just those groups mapped to LDAP, but not whole tree like /* ). When I commented the mapping like this in your TestMembership-configuration.xml file:
{code}
					<field name="ignoreMappedMembershipTypeGroupList">
						<collection type="java.util.ArrayList" item-type="java.lang.String">
							<!--<value>
								<string>/*</string>
							</value>-->
						</collection>
					</field>
{code}
I have correct result. Membership is correctly created and test is passing.

> Membership just added, disappears
> ---------------------------------
>
>                 Key: GTNPORTAL-3493
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3493
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Boubaker Khanfir
>         Attachments: plidm-ldap-membership-disappear.zip
>
>
> I attach a new unit test for a bug that we met in GateIN 3.5 (PL IDM 1.4.4).
> This one shows how we can add a membership and just after that it disappears.
> In this file [idm-configuration.xml|https://github.com/gatein/gatein-portal/blob/3.5.x/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml], the comment :
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For RW LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only and/or Read-only LDAP, it's recommended to not map anything here -->
> {quote}
> is not good and have to be like this:
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only, it's recommended to not map anything here -->
> {quote}
> What changes in this comment ?
> The LDAP RW or ReadOnly have to get the same behavior using this parameter and we should map all LDAP groups in "ignoreMappedMembershipTypeGroupList".
> I think it's better to force/compute this parameter in OrganizationService instead of giving the ability to do it manually. The other solution is to modify OrganizationService Impl to deal with such a use case but I prefer the first choice.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 06:03:17 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 2 Jun 2014 06:03:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3493) Membership just added,
	disappears
In-Reply-To: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541890.1401114872000.8467.1401703397240@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda commented on GTNPORTAL-3493:
------------------------------------------

See documentation https://docs.jboss.org/author/display/GTNPORTAL38/LDAP+integration#LDAPintegration-LDAPasDefaultStore point 6 about "ignoreMappedMembershipTypeGroupList" parameter

> Membership just added, disappears
> ---------------------------------
>
>                 Key: GTNPORTAL-3493
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3493
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Boubaker Khanfir
>         Attachments: plidm-ldap-membership-disappear.zip
>
>
> I attach a new unit test for a bug that we met in GateIN 3.5 (PL IDM 1.4.4).
> This one shows how we can add a membership and just after that it disappears.
> In this file [idm-configuration.xml|https://github.com/gatein/gatein-portal/blob/3.5.x/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml], the comment :
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For RW LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only and/or Read-only LDAP, it's recommended to not map anything here -->
> {quote}
> is not good and have to be like this:
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only, it's recommended to not map anything here -->
> {quote}
> What changes in this comment ?
> The LDAP RW or ReadOnly have to get the same behavior using this parameter and we should map all LDAP groups in "ignoreMappedMembershipTypeGroupList".
> I think it's better to force/compute this parameter in OrganizationService instead of giving the ability to do it manually. The other solution is to modify OrganizationService Impl to deal with such a use case but I prefer the first choice.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:31:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:31:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3497) Portlet in Dashboard
 is broken for the first access
In-Reply-To: <JIRA.12542102.1401266724000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542102.1401266724000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542102.1401266724000.9791.1401715876215@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

>  Portlet in Dashboard is broken for the first access
> ----------------------------------------------------
>
>                 Key: GTNPORTAL-3497
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3497
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> From BZ 1059036: 
> If you configure a richfaces portlet in dashboard template, the portlet may break for the first access by a newly created user.
> https://bugzilla.redhat.com/show_bug.cgi?id=1059036



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Mon Jun  2 09:33:15 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:33:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3485) Add an option to load
 AMD JavaScript from a CDN
In-Reply-To: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541211.1400577402000.9808.1401715995951@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3485:
------------------------------------

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


> Add an option to load AMD JavaScript from a CDN
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3485
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3485
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:33:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:33:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for
 JavaScript and skin services
In-Reply-To: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542445.1401481836000.9810.1401715996144@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3502:
------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:33:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:33:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema
 validation for gatein-resources.xml
In-Reply-To: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542441.1401478549000.9816.1401715996816@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3501:
------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:33:17 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:33:17 -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.9818.1401715997011@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3487:
------------------------------------

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


> 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
>
> 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.3#6260)

From issues at jboss.org  Mon Jun  2 09:33:17 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:33:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3485) Add an option to load
 AMD JavaScript from a CDN
In-Reply-To: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541211.1400577402000.9825.1401715997610@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3485:
------------------------------------

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


> Add an option to load AMD JavaScript from a CDN
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3485
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3485
>             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
>
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:35:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:35:16 -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.9827.1401716116175@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3487:
------------------------------------

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


> 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.3#6260)

From issues at jboss.org  Mon Jun  2 09:35:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:35:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema
 validation for gatein-resources.xml
In-Reply-To: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542441.1401478549000.9831.1401716116391@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3501:
------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:35:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 2 Jun 2014 09:35:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for
 JavaScript and skin services
In-Reply-To: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542445.1401481836000.9829.1401716116289@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3502:
------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:45:19 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:45:19 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3485) Add an option to load
 AMD JavaScript from a CDN
In-Reply-To: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541211.1400577402000.9902.1401716719434@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3485:
-----------------------------------------------

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


> Add an option to load AMD JavaScript from a CDN
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3485
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3485
>             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
>
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:47:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:47:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3485) Add an option to load
 AMD JavaScript from a CDN
In-Reply-To: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541211.1400577402000.9987.1401716835968@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Add an option to load AMD JavaScript from a CDN
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3485
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3485
>             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
>
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:49:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:49:17 -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.9997.1401716957436@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 Update: Perform
    Bugzilla References: 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.3#6260)

From issues at jboss.org  Mon Jun  2 09:49:19 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:49:19 -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.10015.1401716959265@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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.3#6260)

From issues at jboss.org  Mon Jun  2 09:51:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:51:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for
 JavaScript and skin services
In-Reply-To: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542445.1401481836000.10048.1401717077141@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3502:
-----------------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:53:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:53:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for
 JavaScript and skin services
In-Reply-To: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542445.1401481836000.10054.1401717195690@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:55:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:55:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema
 validation for gatein-resources.xml
In-Reply-To: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542441.1401478549000.10057.1401717316232@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3501:
-----------------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 09:55:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 09:55:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema
 validation for gatein-resources.xml
In-Reply-To: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542441.1401478549000.10060.1401717316611@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 10:21:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 2 Jun 2014 10:21:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.10248.1401718875925@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda reassigned GTNPORTAL-3495:
----------------------------------------

    Assignee: Marek Posolda


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 11:41:19 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 2 Jun 2014 11:41:19 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.10467.1401723679009@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda commented on GTNPORTAL-3495:
------------------------------------------

Few comments about this:
1) Your test is not correct as it always read just page1 (memberships.load(0, 5);), so it return it always same results for both call, hence it's not surprising that results are duplicated. I've changed the code of the method "testMembership" like this:

{code}
  @Test
  public void testMembership() throws Exception {

    ExoContainer container = PortalContainer.getInstance();
    OrganizationService service = (OrganizationService) container.getComponentInstance(OrganizationService.class);
    MembershipHandler handler = service.getMembershipHandler();
    Group group = service.getGroupHandler().findGroupById("/test/developers");
    ListAccess<Membership> memberships = handler.findAllMembershipsByGroup(group);

    Set<String> identities = new HashSet<String>();

    int counter = 0;
    int pageNumber = 0;
    while (counter < memberships.getSize()) {
      int remaining = memberships.getSize() - counter;
      int currentPageCount = Math.min(remaining, 5);
      Membership[] membershipsPage = memberships.load(counter, currentPageCount);
      counter += currentPageCount;
      for (Membership membership : membershipsPage) {
        identities.add(membership.getUserName());                 
      }
      System.out.println("Loaded page: " + ++pageNumber + " with " + currentPageCount + " records.");
    }

    System.out.println("All loaded members: " + identities);
    // Assert same count, so no identities has been filtered
    assertEquals(identities.size(), memberships.getSize());
  }
{code}
And now there are 11 memberships in LDAP and all those are properly read in 3 pages (page1 has 5 items, page2 has 5 items and last page just remaining 1 item) and displayed.

2) Parameter "skipPaginationInMembershipQuery" already has default value "true" as you can see here: https://github.com/gatein/gatein-portal/blob/master/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml#L319 . I don't think that it should be removed because for DB-only setup, it can be used to improve performance as with non-mixed (DB only) setup, it's safe to use paginated query in IDM. Unfortunately for mixed DB+LDAP setup, pagination can't be safely used due to reasons, which Bolek already mentioned by email.

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 12:11:15 2014
From: issues at jboss.org (Boubaker Khanfir (JIRA))
Date: Mon, 2 Jun 2014 12:11:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.10618.1401725475986@jira02.app.mwc.hst.phx2.redhat.com>


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

Boubaker Khanfir commented on GTNPORTAL-3495:
---------------------------------------------

Yes, I know the default value is set to true. Sorry for the copy/paste in TestCase, but the first one attached in jbossexo ML didn't get the same page. Anyway,  did you reproduce the problem using skipPaginationInMembershipQuery=false? (After test case change)

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 15:09:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Mon, 2 Jun 2014 15:09:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.11024.1401736155771@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda commented on GTNPORTAL-3495:
------------------------------------------

Option "skipPaginationInMembershipQuery" can be switched to false for improving performance, but that's jut for DB-Only setup. For mixed (DB+LDAP) it should be kept to true to have accurate results.

Pagination of memberships can't be enabled with DB+LDAP because you can have part of users (and their memberships) just in DB, part of them just in LDAP, and part in both. So pagination+sorting is not intended to work. Plain pagination theoretically might work for some LDAP servers, which support pagination extension ( http://www.ietf.org/rfc/rfc2696.txt ) but that's not supported ATM and even if it's implemented in Picketlink IDM, results might not be accurate for DB+LDAP and some memberships will be duplicated.

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 17:03:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 2 Jun 2014 17:03:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNMOP-54) Tests in WorkspaceTestCase
 are order dependent
In-Reply-To: <JIRA.12541101.1400497517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541101.1400497517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541101.1400497517000.11171.1401742995546@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on GTNMOP-54:
-----------------------------------------------

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

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 22:21:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Mon, 2 Jun 2014 22:21:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-29) Implement SPNEGO SSO for
 gatein-tomcat packaging
In-Reply-To: <JIRA.12542592.1401762044749@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542592.1401762044749@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542592.1401762044749.11337.1401762075698@jira02.app.mwc.hst.phx2.redhat.com>

Tuyen Nguyen The created GTNSSO-29:
--------------------------------------

             Summary: Implement SPNEGO SSO for gatein-tomcat packaging
                 Key: GTNSSO-29
                 URL: https://issues.jboss.org/browse/GTNSSO-29
             Project: GateIn SSO
          Issue Type: Feature Request
            Reporter: Tuyen Nguyen The
            Assignee: Marek Posolda


Current spnego sso implementation of gatein only works on jboss because it use Jboss Negotiation library - a specific library for jboss.

So, we need provide other implementation for gatein-tomcat packaging.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  2 22:25:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Mon, 2 Jun 2014 22:25:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNSSO-29) Implement SPNEGO SSO for
 gatein-tomcat packaging
In-Reply-To: <JIRA.12542592.1401762044000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542592.1401762044000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542592.1401762044000.11339.1401762315651@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The updated GTNSSO-29:
-----------------------------------

    Git Pull Request: https://github.com/gatein/gatein-sso/pull/4


> Implement SPNEGO SSO for gatein-tomcat packaging
> ------------------------------------------------
>
>                 Key: GTNSSO-29
>                 URL: https://issues.jboss.org/browse/GTNSSO-29
>             Project: GateIn SSO
>          Issue Type: Feature Request
>            Reporter: Tuyen Nguyen The
>            Assignee: Marek Posolda
>
> Current spnego sso implementation of gatein only works on jboss because it use Jboss Negotiation library - a specific library for jboss.
> So, we need provide other implementation for gatein-tomcat packaging.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 03:33:15 2014
From: issues at jboss.org (Boubaker Khanfir (JIRA))
Date: Tue, 3 Jun 2014 03:33:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.11521.1401780795988@jira02.app.mwc.hst.phx2.redhat.com>


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

Boubaker Khanfir commented on GTNPORTAL-3495:
---------------------------------------------

Ok, I understand. So you intentionally didn't implement the membership pagination using LDAP store. (as seen in method LDAPIdentityStoreImpl.resolveRelationships). Can we make a change in GateIN so that in case we use LDAP/AD in PL IDM, the "skipPaginationInMembershipQuery" is switched automatically, or at least a "log.warn" to say: "Hey, you are using LDAP, switch this flag to 'true' ".

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 04:27:16 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Tue, 3 Jun 2014 04:27:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.11670.1401784036686@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda commented on GTNPORTAL-3495:
------------------------------------------

Hi Boubaker,

There is no easy way to see in GateIn what are underlying identity store implementations. It's abstraction layer, which is not intended to be directly visible by upper layers like GateIn (without doing any hacks).

Btv. I don't get why this is problem. Again, default value of "skipPaginationInMembershipQuery" is "true" as I already mentioned above. And in comment https://github.com/gatein/gatein-portal/blob/master/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml#L317 it's mentioned that for DB+LDAP are people not expected to change this option to "false".

Also in LDAP documentation https://docs.jboss.org/author/display/GTNPORTAL38/LDAP+integration is not anything about this option. So I don't understand why you (or your customers) are switching this option to "false" when they have DB+LDAP setup.

What I can do is to reformulate the comment about this parameter to emphasize more that it's intended to be switched to false just in DB-Only setup . I did it here and will be available in next GateIn version - https://github.com/mposolda/gatein-portal/commit/4cd2d54317191579846557040ed79bc05fffabef

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 05:28:44 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Tue, 3 Jun 2014 05:28:44 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3503) Define a default
 order for page management results
In-Reply-To: <JIRA.12542616.1401787347304@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542616.1401787347304@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542616.1401787347304.11827.1401787724563@jira02.app.mwc.hst.phx2.redhat.com>

Lucas Ponce created GTNPORTAL-3503:
--------------------------------------

             Summary: 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.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.3#6260)

From issues at jboss.org  Tue Jun  3 05:44:16 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Tue, 3 Jun 2014 05:44:16 -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.11900.1401788656408@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3503:
-----------------------------------

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


> 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.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.3#6260)

From issues at jboss.org  Tue Jun  3 05:46:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Jun 2014 05:46:16 -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.11904.1401788776336@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3503:
-----------------------------------------------

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


> 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.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.3#6260)

From issues at jboss.org  Tue Jun  3 05:48:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 3 Jun 2014 05:48:15 -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.11907.1401788895660@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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.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.3#6260)

From issues at jboss.org  Tue Jun  3 06:16:18 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:16:18 -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.12032.1401790578219@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3500:
----------------------------------

    Sprint: Sprint 104


> testMemoryLeakWithMultiThread fails sometimes
> ---------------------------------------------
>
>                 Key: GTNPORTAL-3500
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3500
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1103304
> org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace:
> junit.framework.AssertionFailedError
> 	at junit.framework.Assert.fail(Assert.java:48)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertTrue(Assert.java:27)
> 	at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> The line where it fails is 
> assertTrue(cache.getCacheSize() <= 10);
> Version-Release number of selected component (if applicable):
> GateIn 3.8.x or 3.9.x
> Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and desktop.
> Steps to Reproduce:
> Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests repeatedly until it fails.
> Actual results:
> Test fails
> Expected results:
> Not sure if the subject under the test is broken or the test itself.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:32:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:32:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocal
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.12070.1401791536039@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3499:
----------------------------------

    Sprint: Sprint 104


> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocal
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:34:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:34:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded
 English labels in Title and Field Name
In-Reply-To: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541834.1401072946000.12072.1401791655769@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3491:
----------------------------------

    Sprint: Sprint 104


> [Gadget] Hard-coded English labels in Title and Field Name
> ----------------------------------------------------------
>
>                 Key: GTNPORTAL-3491
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3491
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.5.10.Final, 3.7.1.Final
>            Reporter: H. Trang Vu
>         Attachments: VI-Title-FieldName.png
>
>
> Steps to reproduce:
> * Login as root
> * Go to Application Registry, add *Services Management* gadget into a category
> * Switch to Vietnamese
> * Open Dashboard
> * Add *Services Management* gadget
> * The gadget title is always in English
> * Click pencil icon to edit gadget setting
> ** "Services URL" is always in English



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:34:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:34:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3490) [Services Management
 gadget] Hard-coded English labels
In-Reply-To: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541833.1401072516000.12074.1401791655978@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3490:
----------------------------------

    Sprint: Sprint 104


> [Services Management gadget] Hard-coded English labels
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3490
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3490
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.5.10.Final, 3.7.1.Final
>            Reporter: H. Trang Vu
>            Assignee: H. Trang Vu
>         Attachments: FR-LargeSize-Methods-Properties.png, FR-Properties.png
>
>
> Steps to reproduce:
> * Login as root
> * Go to Application Registry, add *Services Management* gadget into a category
> * Open Dashboard
> * Add *Services Management* gadget
> * Switch to French. 
> * Open the gadget in both normal size and large size
> ** "Methods", "Properties" are still in English.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:34:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:34:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3486) Redirect to /sso
 instead of /login when SSO is enabled
In-Reply-To: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541214.1400578046000.12076.1401791656230@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3486:
----------------------------------

    Sprint: Sprint 104


> Redirect to /sso instead of /login when SSO is enabled
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3486
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3486
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Tuyen Nguyen The
>
> When i configure SPNEGO SSO for Gatein,
> It work ok when i login with "login" link at top navigation bar. But when i try to access to page that rerquire login, (for example http://server.local.network:8080/portal/g/:platform:administrators/administration/registry), it will redirect to /login and i will not be logged in automatically with SPNEGO because spnego only work when it redirect to /dologin
> I think when SSO is enabled, we should redirect to /sso instead of /login when user try to access page that require login, then SSO will redirect to loginURL which was configured. 
> It's similar that we change link of "login" at top navigation bar to /sso when SSO is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:36:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:36:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3477) Make GadgetImporter
 throw an exception with a meaningful message
In-Reply-To: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540360.1399651321000.12079.1401791775707@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3477:
----------------------------------

    Sprint: Sprint 104


> Make GadgetImporter throw an exception with a meaningful message
> ----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3477
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3477
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>
> {{GadgetImporter}} throws {{new IOException()}} without message and logs {{"Cannot import gadget " + gadgetURI + " because its data could not be found"}} on the previous line. We should apply both of the following:
> (1) Either throw or log not both
> (2) Throw exceptions with informative messages.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:36:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 3 Jun 2014 06:36:15 -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.12081.1401791775864@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong updated GTNPORTAL-3500:
--------------------------------------

     Original Estimate: 1 day, 4 hours
    Remaining Estimate: 1 day, 4 hours


> 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
>   Original Estimate: 1 day, 4 hours
>  Remaining Estimate: 1 day, 4 hours
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1103304
> org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace:
> junit.framework.AssertionFailedError
> 	at junit.framework.Assert.fail(Assert.java:48)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertTrue(Assert.java:27)
> 	at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> The line where it fails is 
> assertTrue(cache.getCacheSize() <= 10);
> Version-Release number of selected component (if applicable):
> GateIn 3.8.x or 3.9.x
> Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and desktop.
> Steps to Reproduce:
> Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests repeatedly until it fails.
> Actual results:
> Test fails
> Expected results:
> Not sure if the subject under the test is broken or the test itself.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:38:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 06:38:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3450) Impossible to upload
 file in Content Explorer when tmpdir does not exist
In-Reply-To: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538741.1398162661000.12087.1401791896396@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3450:
----------------------------------

    Sprint: Sprint 104


> Impossible to upload file in Content Explorer when tmpdir does not exist
> ------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3450
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3450
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>
> We have a problem when trying to upload files.
> We noticed that the "org.exoplatform.upload.UploadService" Service uses java.io.tmpdir (System Properties) to create the portal/eXoUpload directory needed to upload files.
> If the directory does not exist (ie, deleted : custermer's case deleted by tmpwatch command).
> << we can view the file tree but nothing happens, it stays at 0 % (blocking).
> *Error log:* 
> {code}DEBUG [org.exoplatform.upload.UploadService] (ajp-10.11.2.212-8009-42) IOException while upload resource
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
> 	at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:120)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:96)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:123)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:60)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:358)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:125)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:84)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:54)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:114)
> 	at com.filhetallard.dis.extranet.adp.portlet.common.SitesAccessFilter.doFilter(SitesAccessFilter.java:195)
> 	at com.filhetallard.dis.extranet.fac.exo.web.FilterAdapter.doFilter(FilterAdapter.java:23)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.platform.common.admin.TermsAndConditionsFilter.doFilter(TermsAndConditionsFilter.java:77)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:84)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:385)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> 	at java.lang.Thread.run(Thread.java:701)
> Caused by: java.io.FileNotFoundException: /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:160)
> 	at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
> 	... 65 more{code}



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:50:16 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 3 Jun 2014 06:50:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocal
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.12130.1401792616240@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong updated GTNPORTAL-3499:
--------------------------------------

     Original Estimate: 6 hours
    Remaining Estimate: 6 hours


> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocal
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:52:16 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 3 Jun 2014 06:52:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded
 English labels in Title and Field Name
In-Reply-To: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541834.1401072946000.12141.1401792736238@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong updated GTNPORTAL-3491:
--------------------------------------

     Original Estimate: 4 hours
    Remaining Estimate: 4 hours


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 06:54:16 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 3 Jun 2014 06:54:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3490) [Services Management
 gadget] Hard-coded English labels
In-Reply-To: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541833.1401072516000.12150.1401792856765@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong updated GTNPORTAL-3490:
--------------------------------------

     Original Estimate: 1 hour
    Remaining Estimate: 1 hour


> [Services Management gadget] Hard-coded English labels
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3490
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3490
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.5.10.Final, 3.7.1.Final
>            Reporter: H. Trang Vu
>            Assignee: H. Trang Vu
>         Attachments: FR-LargeSize-Methods-Properties.png, FR-Properties.png
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Steps to reproduce:
> * Login as root
> * Go to Application Registry, add *Services Management* gadget into a category
> * Open Dashboard
> * Add *Services Management* gadget
> * Switch to French. 
> * Open the gadget in both normal size and large size
> ** "Methods", "Properties" are still in English.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 07:12:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 3 Jun 2014 07:12:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3486) Redirect to /sso
 instead of /login when SSO is enabled
In-Reply-To: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541214.1400578046000.12176.1401793935789@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong updated GTNPORTAL-3486:
--------------------------------------

     Original Estimate: 4 hours
    Remaining Estimate: 4 hours


> Redirect to /sso instead of /login when SSO is enabled
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3486
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3486
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> When i configure SPNEGO SSO for Gatein,
> It work ok when i login with "login" link at top navigation bar. But when i try to access to page that rerquire login, (for example http://server.local.network:8080/portal/g/:platform:administrators/administration/registry), it will redirect to /login and i will not be logged in automatically with SPNEGO because spnego only work when it redirect to /dologin
> I think when SSO is enabled, we should redirect to /sso instead of /login when user try to access page that require login, then SSO will redirect to loginURL which was configured. 
> It's similar that we change link of "login" at top navigation bar to /sso when SSO is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 07:14:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Tue, 3 Jun 2014 07:14:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3477) Make GadgetImporter
 throw an exception with a meaningful message
In-Reply-To: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540360.1399651321000.12178.1401794055808@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong updated GTNPORTAL-3477:
--------------------------------------

     Original Estimate: 2 hours
    Remaining Estimate: 2 hours


> Make GadgetImporter throw an exception with a meaningful message
> ----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3477
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3477
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> {{GadgetImporter}} throws {{new IOException()}} without message and logs {{"Cannot import gadget " + gadgetURI + " because its data could not be found"}} on the previous line. We should apply both of the following:
> (1) Either throw or log not both
> (2) Throw exceptions with informative messages.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 07:20:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 07:20:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3450) Impossible to upload
 file in Content Explorer when tmpdir does not exist
In-Reply-To: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538741.1398162661000.12191.1401794415820@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3450:
----------------------------------

     Original Estimate: 1 hour
    Remaining Estimate: 1 hour


> Impossible to upload file in Content Explorer when tmpdir does not exist
> ------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3450
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3450
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> We have a problem when trying to upload files.
> We noticed that the "org.exoplatform.upload.UploadService" Service uses java.io.tmpdir (System Properties) to create the portal/eXoUpload directory needed to upload files.
> If the directory does not exist (ie, deleted : custermer's case deleted by tmpwatch command).
> << we can view the file tree but nothing happens, it stays at 0 % (blocking).
> *Error log:* 
> {code}DEBUG [org.exoplatform.upload.UploadService] (ajp-10.11.2.212-8009-42) IOException while upload resource
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
> 	at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:120)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:96)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:123)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:60)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:358)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:125)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:84)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:54)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:114)
> 	at com.filhetallard.dis.extranet.adp.portlet.common.SitesAccessFilter.doFilter(SitesAccessFilter.java:195)
> 	at com.filhetallard.dis.extranet.fac.exo.web.FilterAdapter.doFilter(FilterAdapter.java:23)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.platform.common.admin.TermsAndConditionsFilter.doFilter(TermsAndConditionsFilter.java:77)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:84)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:385)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> 	at java.lang.Thread.run(Thread.java:701)
> Caused by: java.io.FileNotFoundException: /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:160)
> 	at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
> 	... 65 more{code}



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 22:04:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:04:15 -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.14423.1401847455710@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran reassigned GTNPORTAL-3500:
-------------------------------------

    Assignee: Trong Tran


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 22:04:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:04:15 -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.14426.1401847455953@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on GTNPORTAL-3500 started by Trong Tran.

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 22:04:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:04:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3450) Impossible to upload
 file in Content Explorer when tmpdir does not exist
In-Reply-To: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538741.1398162661000.14429.1401847456349@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran reassigned GTNPORTAL-3450:
-------------------------------------

    Assignee: Trong Tran


> Impossible to upload file in Content Explorer when tmpdir does not exist
> ------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3450
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3450
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Trong Tran
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> We have a problem when trying to upload files.
> We noticed that the "org.exoplatform.upload.UploadService" Service uses java.io.tmpdir (System Properties) to create the portal/eXoUpload directory needed to upload files.
> If the directory does not exist (ie, deleted : custermer's case deleted by tmpwatch command).
> << we can view the file tree but nothing happens, it stays at 0 % (blocking).
> *Error log:* 
> {code}DEBUG [org.exoplatform.upload.UploadService] (ajp-10.11.2.212-8009-42) IOException while upload resource
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
> 	at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:120)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:96)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:123)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:60)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:358)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:125)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:84)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:54)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:114)
> 	at com.filhetallard.dis.extranet.adp.portlet.common.SitesAccessFilter.doFilter(SitesAccessFilter.java:195)
> 	at com.filhetallard.dis.extranet.fac.exo.web.FilterAdapter.doFilter(FilterAdapter.java:23)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.platform.common.admin.TermsAndConditionsFilter.doFilter(TermsAndConditionsFilter.java:77)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:84)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:385)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> 	at java.lang.Thread.run(Thread.java:701)
> Caused by: java.io.FileNotFoundException: /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:160)
> 	at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
> 	... 65 more{code}



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 22:24:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:24:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3367) Cannot login as user
 whose password contains accent character
In-Reply-To: <JIRA.12529449.1389768190000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529449.1389768190000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529449.1389768190000.14438.1401848656284@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3367:
----------------------------------

    Fix Version/s: 3.5.11.Final
                       (was: 3.5.10.Final)


> Cannot login as user whose password contains accent character
> -------------------------------------------------------------
>
>                 Key: GTNPORTAL-3367
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3367
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Trong Tran
>            Priority: Minor
>             Fix For: 3.5.11.Final
>
>
> - Integrate Gatein with LDAP
> - Create at LDAP a user whose password contains accent character e.g. *ABe1-(1?1*
> - Try to login
> -> Cannot login



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Tue Jun  3 22:24:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:24:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3366) [IE8,
 IE9] Can not rename Dashboard tab if name contains accent chars
In-Reply-To: <JIRA.12529443.1389757902000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529443.1389757902000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529443.1389757902000.14440.1401848656493@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3366:
----------------------------------

    Fix Version/s: 3.5.11.Final
                       (was: 3.5.10.Final)


> [IE8, IE9] Can not rename Dashboard tab if name contains accent chars
> ---------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3366
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3366
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>             Fix For: 3.5.11.Final, 3.9.0.Final
>
>
> Steps to reproduce:
> - Login
> - Create a Dashboard page
> - Go to that page, create a new tab of which name contains accent chars (i.e. s? m?i kh?o d?i)
> - Edit name of that tab by deleting some chars in the name (i.e.: s? m?i)
> - Hit Enter
> >>> Result: can not rename



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Tue Jun  3 22:26:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:26:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3450) Impossible to upload
 file in Content Explorer when tmpdir does not exist
In-Reply-To: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538741.1398162661000.14445.1401848775864@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3450:
----------------------------------

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


> Impossible to upload file in Content Explorer when tmpdir does not exist
> ------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3450
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3450
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> We have a problem when trying to upload files.
> We noticed that the "org.exoplatform.upload.UploadService" Service uses java.io.tmpdir (System Properties) to create the portal/eXoUpload directory needed to upload files.
> If the directory does not exist (ie, deleted : custermer's case deleted by tmpwatch command).
> << we can view the file tree but nothing happens, it stays at 0 % (blocking).
> *Error log:* 
> {code}DEBUG [org.exoplatform.upload.UploadService] (ajp-10.11.2.212-8009-42) IOException while upload resource
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
> 	at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:120)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:96)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:123)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:60)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:358)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:125)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:84)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:54)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:114)
> 	at com.filhetallard.dis.extranet.adp.portlet.common.SitesAccessFilter.doFilter(SitesAccessFilter.java:195)
> 	at com.filhetallard.dis.extranet.fac.exo.web.FilterAdapter.doFilter(FilterAdapter.java:23)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.platform.common.admin.TermsAndConditionsFilter.doFilter(TermsAndConditionsFilter.java:77)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:84)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:385)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> 	at java.lang.Thread.run(Thread.java:701)
> Caused by: java.io.FileNotFoundException: /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:160)
> 	at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
> 	... 65 more{code}



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 22:26:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 22:26:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3450) Impossible to upload
 file in Content Explorer when tmpdir does not exist
In-Reply-To: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538741.1398162661000.14448.1401848776087@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3450:
----------------------------------

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


> Impossible to upload file in Content Explorer when tmpdir does not exist
> ------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3450
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3450
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> We have a problem when trying to upload files.
> We noticed that the "org.exoplatform.upload.UploadService" Service uses java.io.tmpdir (System Properties) to create the portal/eXoUpload directory needed to upload files.
> If the directory does not exist (ie, deleted : custermer's case deleted by tmpwatch command).
> << we can view the file tree but nothing happens, it stays at 0 % (blocking).
> *Error log:* 
> {code}DEBUG [org.exoplatform.upload.UploadService] (ajp-10.11.2.212-8009-42) IOException while upload resource
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
> 	at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:120)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:96)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:123)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:60)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:358)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:125)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:84)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:54)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:114)
> 	at com.filhetallard.dis.extranet.adp.portlet.common.SitesAccessFilter.doFilter(SitesAccessFilter.java:195)
> 	at com.filhetallard.dis.extranet.fac.exo.web.FilterAdapter.doFilter(FilterAdapter.java:23)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.platform.common.admin.TermsAndConditionsFilter.doFilter(TermsAndConditionsFilter.java:77)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:84)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:385)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> 	at java.lang.Thread.run(Thread.java:701)
> Caused by: java.io.FileNotFoundException: /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:160)
> 	at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
> 	... 65 more{code}



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun  3 23:06:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 3 Jun 2014 23:06:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3450) Impossible to upload
 file in Content Explorer when tmpdir does not exist
In-Reply-To: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538741.1398162661000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538741.1398162661000.14458.1401851175690@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3450?focusedWorklogId=12431301&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12431301 ]

Trong Tran logged work on GTNPORTAL-3450:
-----------------------------------------

                Author: Trong Tran
            Created on: 03/Jun/14 11:04 PM
            Start Date: 03/Jun/14 11:04 PM
    Worklog Time Spent: 1 hour 

Issue Time Tracking
-------------------

    Remaining Estimate: 0 minutes  (was: 1 hour)
            Time Spent: 1 hour
            Worklog Id:     (was: 12431301)


> Impossible to upload file in Content Explorer when tmpdir does not exist
> ------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3450
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3450
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.8.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>   Original Estimate: 1 hour
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>
> We have a problem when trying to upload files.
> We noticed that the "org.exoplatform.upload.UploadService" Service uses java.io.tmpdir (System Properties) to create the portal/eXoUpload directory needed to upload files.
> If the directory does not exist (ie, deleted : custermer's case deleted by tmpwatch command).
> << we can view the file tree but nothing happens, it stays at 0 % (blocking).
> *Error log:* 
> {code}DEBUG [org.exoplatform.upload.UploadService] (ajp-10.11.2.212-8009-42) IOException while upload resource
> org.apache.commons.fileupload.FileUploadBase$IOFileUploadException: Processing of multipart/form-data request failed. /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:367)
> 	at org.apache.commons.fileupload.servlet.ServletFileUpload.parseRequest(ServletFileUpload.java:126)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:120)
> 	at org.exoplatform.upload.UploadService.createUploadResource(UploadService.java:96)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:123)
> 	at org.exoplatform.web.handler.UploadHandler.execute(UploadHandler.java:60)
> 	at org.exoplatform.web.WebAppController.service(WebAppController.java:358)
> 	at org.exoplatform.portal.application.PortalController.onService(PortalController.java:125)
> 	at org.exoplatform.container.web.AbstractHttpServlet.service(AbstractHttpServlet.java:132)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:84)
> 	at org.exoplatform.web.login.RememberMeFilter.doFilter(RememberMeFilter.java:54)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:114)
> 	at com.filhetallard.dis.extranet.adp.portlet.common.SitesAccessFilter.doFilter(SitesAccessFilter.java:195)
> 	at com.filhetallard.dis.extranet.fac.exo.web.FilterAdapter.doFilter(FilterAdapter.java:23)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.platform.common.admin.TermsAndConditionsFilter.doFilter(TermsAndConditionsFilter.java:77)
> 	at org.exoplatform.web.filter.ExtensibleFilter$ExtensibleFilterChain.doFilter(ExtensibleFilter.java:110)
> 	at org.exoplatform.web.filter.ExtensibleFilter.doFilter(ExtensibleFilter.java:84)
> 	at org.exoplatform.web.filter.GenericFilter.doFilter(GenericFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.CacheUserProfileFilter.doFilter(CacheUserProfileFilter.java:78)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.frameworks.jcr.web.ThreadLocalSessionProviderInitializedFilter.doFilter(ThreadLocalSessionProviderInitializedFilter.java:116)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.services.security.web.SetCurrentIdentityFilter.doFilter(SetCurrentIdentityFilter.java:88)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.web.login.ClusteredSSOFilter.doFilter(ClusteredSSOFilter.java:62)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.exoplatform.container.web.PortalContainerFilter.doFilter(PortalContainerFilter.java:69)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> 	at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.handleRequest(ClusteredSessionValve.java:135)
> 	at org.jboss.web.tomcat.service.session.ClusteredSessionValve.invoke(ClusteredSessionValve.java:94)
> 	at org.jboss.web.tomcat.service.session.JvmRouteValve.invoke(JvmRouteValve.java:88)
> 	at org.jboss.web.tomcat.service.session.LockingValve.invoke(LockingValve.java:62)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> 	at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> 	at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> 	at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:402)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.internalProcess(ActiveRequestResponseCacheValve.java:74)
> 	at org.jboss.web.tomcat.service.request.ActiveRequestResponseCacheValve.invoke(ActiveRequestResponseCacheValve.java:47)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> 	at org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:436)
> 	at org.apache.coyote.ajp.AjpProtocol$AjpConnectionHandler.process(AjpProtocol.java:385)
> 	at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
> 	at java.lang.Thread.run(Thread.java:701)
> Caused by: java.io.FileNotFoundException: /tmp/portal/eXoUpload/upload__175985d8_14550fb3b24_d1a_00000003.tmp (Aucun fichier ou dossier de ce type)
> 	at java.io.FileOutputStream.open(Native Method)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:212)
> 	at java.io.FileOutputStream.<init>(FileOutputStream.java:160)
> 	at org.apache.commons.io.output.DeferredFileOutputStream.thresholdReached(DeferredFileOutputStream.java:165)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.checkThreshold(ThresholdingOutputStream.java:221)
> 	at org.apache.commons.io.output.ThresholdingOutputStream.write(ThresholdingOutputStream.java:127)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:101)
> 	at org.apache.commons.fileupload.util.Streams.copy(Streams.java:64)
> 	at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:362)
> 	... 65 more{code}



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 02:20:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 02:20:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764011@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764011@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764011.14510.1401862815232@jira02.app.mwc.hst.phx2.redhat.com>

Marek Posolda created GTNPORTAL-3504:
----------------------------------------

             Summary: Upgrade Picketlink IDM to 1.4.5.Final
                 Key: GTNPORTAL-3504
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
             Project: GateIn Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
    Affects Versions: 3.8.1.Final
            Reporter: Marek Posolda
            Assignee: Marek Posolda
             Fix For: 3.8.2.Final, 3.9.0.Final






--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:36:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:36:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764000.14678.1401867375924@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3504:
-------------------------------------

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


> Upgrade Picketlink IDM to 1.4.5.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3504
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.1.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:36:16 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:36:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764000.14684.1401867376401@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3504:
-------------------------------------

    Fix Version/s: 3.8.3.Final
                       (was: 3.8.2.Final)


> Upgrade Picketlink IDM to 1.4.5.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3504
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.1.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:38:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:38:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.14689.1401867495869@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3495:
-------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:38:16 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:38:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.14691.1401867496011@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3495:
-------------------------------------

    Fix Version/s: 3.8.3.Final
                   3.9.0.Final


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:38:16 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:38:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.14693.1401867496189@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda commented on GTNPORTAL-3495:
------------------------------------------

Sent PR with small update of comment for "skipPaginationInMembershipQuery" property

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:40:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:40:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3493) Membership just added,
	disappears
In-Reply-To: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541890.1401114872000.14699.1401867615606@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3493:
-------------------------------------

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


Sent PR with small update for ignoreMappedMembershipTypeGroupList property

> Membership just added, disappears
> ---------------------------------
>
>                 Key: GTNPORTAL-3493
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3493
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Boubaker Khanfir
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>         Attachments: plidm-ldap-membership-disappear.zip
>
>
> I attach a new unit test for a bug that we met in GateIN 3.5 (PL IDM 1.4.4).
> This one shows how we can add a membership and just after that it disappears.
> In this file [idm-configuration.xml|https://github.com/gatein/gatein-portal/blob/3.5.x/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml], the comment :
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For RW LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only and/or Read-only LDAP, it's recommended to not map anything here -->
> {quote}
> is not good and have to be like this:
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only, it's recommended to not map anything here -->
> {quote}
> What changes in this comment ?
> The LDAP RW or ReadOnly have to get the same behavior using this parameter and we should map all LDAP groups in "ignoreMappedMembershipTypeGroupList".
> I think it's better to force/compute this parameter in OrganizationService instead of giving the ability to do it manually. The other solution is to modify OrganizationService Impl to deal with such a use case but I prefer the first choice.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 03:40:15 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 03:40:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3493) Membership just added,
	disappears
In-Reply-To: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541890.1401114872000.14701.1401867615744@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3493:
-------------------------------------

        Fix Version/s: 3.8.3.Final
                       3.9.0.Final
             Assignee: Marek Posolda
    Affects Version/s:     (was: 3.5.9.Final)


> Membership just added, disappears
> ---------------------------------
>
>                 Key: GTNPORTAL-3493
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3493
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Boubaker Khanfir
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>         Attachments: plidm-ldap-membership-disappear.zip
>
>
> I attach a new unit test for a bug that we met in GateIN 3.5 (PL IDM 1.4.4).
> This one shows how we can add a membership and just after that it disappears.
> In this file [idm-configuration.xml|https://github.com/gatein/gatein-portal/blob/3.5.x/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml], the comment :
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For RW LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only and/or Read-only LDAP, it's recommended to not map anything here -->
> {quote}
> is not good and have to be like this:
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only, it's recommended to not map anything here -->
> {quote}
> What changes in this comment ?
> The LDAP RW or ReadOnly have to get the same behavior using this parameter and we should map all LDAP groups in "ignoreMappedMembershipTypeGroupList".
> I think it's better to force/compute this parameter in OrganizationService instead of giving the ability to do it manually. The other solution is to modify OrganizationService Impl to deal with such a use case but I prefer the first choice.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun  4 04:16:16 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Wed, 4 Jun 2014 04:16:16 -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.14751.1401869776275@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3494:
-------------------------------------

    Fix Version/s: 3.8.3.Final
                       (was: 3.8.2.Final)


> 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.3#6260)

From issues at jboss.org  Wed Jun  4 10:38:16 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Wed, 4 Jun 2014 10:38:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind
 Load Balancers get wrong endpoint URL
In-Reply-To: <JIRA.12542783.1401892628569@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542783.1401892628569@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542783.1401892628569.16010.1401892696354@jira02.app.mwc.hst.phx2.redhat.com>

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

             Summary: WSRP Producers behind Load Balancers get wrong endpoint URL
                 Key: GTNPORTAL-3505
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Juraci Paix?o Kr?hling
            Assignee: Juraci Paix?o Kr?hling


When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and 1102733.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Wed Jun  4 10:40:16 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Wed, 4 Jun 2014 10:40:16 -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.16020.1401892816362@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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


> WSRP Producers behind Load Balancers get wrong endpoint URL
> -----------------------------------------------------------
>
>                 Key: GTNPORTAL-3505
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and 1102733.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Wed Jun  4 11:24:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 4 Jun 2014 11:24:16 -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.16355.1401895456354@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Different Portlet preference for remote portlets added on the same page
> -----------------------------------------------------------------------
>
>                 Key: GTNWSRP-376
>                 URL: https://issues.jboss.org/browse/GTNWSRP-376
>             Project: GateIn WSRP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.11.Final
>         Environment: Tested with :
> JBoss Portal Platform - 6.1.1 (GateIn Portal 3.6.5)  and 
> GateIn-3.8.0.Beta01
>            Reporter: Anurag Debnath
>            Assignee: Juraci Paix?o Kr?hling
>         Attachments: PortletPreferencesPortlet.war.zip
>
>
> When two instances of the same remote portlet is added to the same page, changes made to the preferences of one portlet is picked up by the other portlet as well.
> Ideally, portlets should get their own preference/s.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Wed Jun  4 11:24:17 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Wed, 4 Jun 2014 11:24:17 -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.16365.1401895457304@jira02.app.mwc.hst.phx2.redhat.com>


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

Juraci Paix?o Kr?hling closed GTNWSRP-376.
------------------------------------------

    Resolution: Done


Merged: https://github.com/gatein/gatein-wsrp/commit/631f7f0dc913df28675e258cb07531a007d6f2fc

> Different Portlet preference for remote portlets added on the same page
> -----------------------------------------------------------------------
>
>                 Key: GTNWSRP-376
>                 URL: https://issues.jboss.org/browse/GTNWSRP-376
>             Project: GateIn WSRP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.11.Final
>         Environment: Tested with :
> JBoss Portal Platform - 6.1.1 (GateIn Portal 3.6.5)  and 
> GateIn-3.8.0.Beta01
>            Reporter: Anurag Debnath
>            Assignee: Juraci Paix?o Kr?hling
>         Attachments: PortletPreferencesPortlet.war.zip
>
>
> When two instances of the same remote portlet is added to the same page, changes made to the preferences of one portlet is picked up by the other portlet as well.
> Ideally, portlets should get their own preference/s.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Wed Jun  4 22:00:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Wed, 4 Jun 2014 22:00:16 -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.17833.1401933616075@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran logged work on GTNPORTAL-3500:
-----------------------------------------

                Author: Trong Tran
            Created on: 04/Jun/14 9:58 PM
            Start Date: 04/Jun/14 9:58 AM
    Worklog Time Spent: 4 hours 

Issue Time Tracking
-------------------

    Remaining Estimate: 1 day  (was: 1 day, 4 hours)
            Time Spent: 4 hours
            Worklog Id:     (was: 12431302)


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 04:10:15 2014
From: issues at jboss.org (=?UTF-8?Q?Juraci_Paix=C3=A3o_Kr=C3=B6hling_=28JIRA=29?=)
Date: Thu, 5 Jun 2014 04:10:15 -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.18184.1401955815268@jira02.app.mwc.hst.phx2.redhat.com>


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

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

    Description: When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.  (was: When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and 1102733.)


> WSRP Producers behind Load Balancers get wrong endpoint URL
> -----------------------------------------------------------
>
>                 Key: GTNPORTAL-3505
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Thu Jun  5 04:12:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Jun 2014 04:12:15 -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.18186.1401955935540@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3505:
-----------------------------------------------

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


> WSRP Producers behind Load Balancers get wrong endpoint URL
> -----------------------------------------------------------
>
>                 Key: GTNPORTAL-3505
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Thu Jun  5 04:12:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Jun 2014 04:12:15 -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.18188.1401955935714@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> WSRP Producers behind Load Balancers get wrong endpoint URL
> -----------------------------------------------------------
>
>                 Key: GTNPORTAL-3505
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Thu Jun  5 05:04:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 5 Jun 2014 05:04:16 -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.18296.1401959056330@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3500:
----------------------------------

    Attachment: TestDownloadService.java


It's not easy to reproduce the issue actually. However, I have made some changes to get the problem occurred more frequently (attached test case)

The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's normal

I think we could deactivate the usecase. if we consider this is a real case, we could create an issue in eXo Kernel instead.

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 05:06:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 5 Jun 2014 05:06:16 -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.18316.1401959176890@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran edited comment on GTNPORTAL-3500 at 6/5/14 5:04 AM:
---------------------------------------------------------------

It's not easy to reproduce the issue actually. However, I have made some changes to get the problem occurred more frequently (attached test case)

The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's acceptable.

I think we could deactivate the usecase. if we consider this is a real case, we could create an issue in eXo Kernel instead.


was (Author: trong.tran):
It's not easy to reproduce the issue actually. However, I have made some changes to get the problem occurred more frequently (attached test case)

The root problem is that it's using ConcurrentFIFOExoCache for holding resources temporarily. This test is to assert the cached objects size == max size BUT in the case of multi-threading, it can not be 100% sure that cacheSize == maxSize at any time as it needs a little time to execute the cache eviction. ===> for me, it's normal

I think we could deactivate the usecase. if we consider this is a real case, we could create an issue in eXo Kernel instead.

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:02:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Thu, 5 Jun 2014 06:02:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded
 English labels in Title and Field Name
In-Reply-To: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541834.1401072946000.18729.1401962535699@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The reassigned GTNPORTAL-3491:
-------------------------------------------

    Assignee: Tuyen Nguyen The


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:02:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Thu, 5 Jun 2014 06:02:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded
 English labels in Title and Field Name
In-Reply-To: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541834.1401072946000.18731.1401962535892@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on GTNPORTAL-3491 started by Tuyen Nguyen The.

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:16:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 5 Jun 2014 06:16:16 -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.18754.1401963376412@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran resolved GTNPORTAL-3500.
-----------------------------------

    Fix Version/s: 3.9.0.Final
       Resolution: Done


> 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: 4 hours
>  Remaining Estimate: 1 day
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1103304
> org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread() fails in some cases. The stack trace:
> junit.framework.AssertionFailedError
> 	at junit.framework.Assert.fail(Assert.java:48)
> 	at junit.framework.Assert.assertTrue(Assert.java:20)
> 	at junit.framework.Assert.assertTrue(Assert.java:27)
> 	at org.exoplatform.download.TestDownloadService.testMemoryLeakWithMultiThread(TestDownloadService.java:109)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ...
> The line where it fails is 
> assertTrue(cache.getCacheSize() <= 10);
> Version-Release number of selected component (if applicable):
> GateIn 3.8.x or 3.9.x
> Reproducible sometimes: 1/10 or even less. Happens both on Jenkins and desktop.
> Steps to Reproduce:
> Not sure. It happens randomly. Perhaps overloading the machine with some CPU-intensive task might help. Just build the exo.portal.component.web.server artifact with tests repeatedly until it fails.
> Actual results:
> Test fails
> Expected results:
> Not sure if the subject under the test is broken or the test itself.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:22:17 2014
From: issues at jboss.org (Takayuki Konishi (JIRA))
Date: Thu, 5 Jun 2014 06:22:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot
 decode surrogate pair characters
In-Reply-To: <JIRA.12542903.1401963673946@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542903.1401963673946@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542903.1401963673946.18788.1401963737521@jira02.app.mwc.hst.phx2.redhat.com>

Takayuki Konishi created GTNCOMMON-24:
-----------------------------------------

             Summary: FastURLDecoder cannot decode surrogate pair characters
                 Key: GTNCOMMON-24
                 URL: https://issues.jboss.org/browse/GTNCOMMON-24
             Project: GateIn Common
          Issue Type: Bug
            Reporter: Takayuki Konishi


FastURLDecoder cannot decode surrogate pair characters.
{code}
org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
{code}
I also attach a patch for testcase.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:24:15 2014
From: issues at jboss.org (Takayuki Konishi (JIRA))
Date: Thu, 5 Jun 2014 06:24:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot
 decode surrogate pair characters
In-Reply-To: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542903.1401963673000.18792.1401963855665@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayuki Konishi updated GTNCOMMON-24:
--------------------------------------

    Attachment: surrogatepairtest.patch


> FastURLDecoder cannot decode surrogate pair characters
> ------------------------------------------------------
>
>                 Key: GTNCOMMON-24
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-24
>             Project: GateIn Common
>          Issue Type: Bug
>            Reporter: Takayuki Konishi
>         Attachments: surrogatepairtest.patch
>
>
> FastURLDecoder cannot decode surrogate pair characters.
> {code}
> org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
> 	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
> 	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
> {code}
> I also attach a patch for testcase.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:26:16 2014
From: issues at jboss.org (Takayuki Konishi (JIRA))
Date: Thu, 5 Jun 2014 06:26:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot
 decode surrogate pair characters
In-Reply-To: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542903.1401963673000.18803.1401963976449@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayuki Konishi updated GTNCOMMON-24:
--------------------------------------

    Description: 
FastURLDecoder cannot decode surrogate pair characters.

When I decoded U+20000B, I got MalformedInputException:
{code}
org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
{code}
I also attach a patch for testcase.

  was:
FastURLDecoder cannot decode surrogate pair characters.
{code}
org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
{code}
I also attach a patch for testcase.



> FastURLDecoder cannot decode surrogate pair characters
> ------------------------------------------------------
>
>                 Key: GTNCOMMON-24
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-24
>             Project: GateIn Common
>          Issue Type: Bug
>            Reporter: Takayuki Konishi
>         Attachments: surrogatepairtest.patch
>
>
> FastURLDecoder cannot decode surrogate pair characters.
> When I decoded U+20000B, I got MalformedInputException:
> {code}
> org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
> 	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
> 	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
> {code}
> I also attach a patch for testcase.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 06:28:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 5 Jun 2014 06:28:16 -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.18815.1401964096499@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran logged work on GTNPORTAL-3500:
-----------------------------------------

                Author: Trong Tran
            Created on: 05/Jun/14 6:26 AM
            Start Date: 05/Jun/14 6:26 AM
    Worklog Time Spent: 4 hours 

Issue Time Tracking
-------------------

    Remaining Estimate: 0 minutes  (was: 1 day)
            Time Spent: 1 day  (was: 4 hours)
            Worklog Id:     (was: 12431303)


> 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.3#6260)

From issues at jboss.org  Thu Jun  5 07:28:15 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 5 Jun 2014 07:28:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3506) Allow multiple apps
 registering the very same AMD paths
In-Reply-To: <JIRA.12542915.1401967625498@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542915.1401967625498@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542915.1401967625498.18929.1401967695589@jira02.app.mwc.hst.phx2.redhat.com>

Peter Palaga created GTNPORTAL-3506:
---------------------------------------

             Summary: Allow multiple apps registering the very same AMD paths
                 Key: GTNPORTAL-3506
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3506
             Project: GateIn Portal
          Issue Type: Task
      Security Level: Public (Everyone can see)
            Reporter: Peter Palaga
            Assignee: Peter Palaga


h4. Current state
GTNPORTAL-3502 introduced a common deployer for JavaScript and skin services with the following characteristics: when an app attempts to add an AMD path mapping that is available in the portal already,
all JS and CSS resources from that app are rejected. The path mapping comparison is done on path prefixes only, the target paths are not inspected at all. 

Example:
* Application {{app.war}} wants to register the AMD module ID prefix
   {{/dojo}} to be mapped to target path {{http://fastcdn.com/dojo/1.7.0}}
* But the prefix {{/dojo}} was registered already for
   {{http://othercdn.com/dojo/1.9.1}} by some other application.
* All JS and CSS resources from {{app.war}} are rejected by skin and JSConfig services.

h4. Proposed change
The above approach is unnecessarily restrictive, because it rejects also applications that want to register the very same target path for a given prefix as is registered in the portal already.

Example:
* Application {{app2.war}} wants to register the AMD module ID prefix
   {{/dojo}} to be mapped to target path {{http://fastcdn.com/dojo/1.7.0}}
* The prefix {{/dojo}} was previously registered by some other application {{app1.war}} to point to the very same target path {{http://fastcdn.com/dojo/1.7.0}}.
* JS and CSS resources from {{app2.war}} should be accepted by the portal because no inconsistency is introduced by {{app2.war}}.
* However, having accepted two or more apps relying on one path mapping, the portal must reject all changes that could break any of the affected applications. E.g. the portal may not remove the mapping on {{app1.war}} undeploy or it may not allow for re-deploying {{app1.war}} with a modified path mapping while {{app2.war}} is still active.




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 09:56:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 5 Jun 2014 09:56:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3470) Make permission
 defaults in page creation forms consistent
In-Reply-To: <JIRA.12539791.1399117226000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12539791.1399117226000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539791.1399117226000.19557.1401976575679@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Make permission defaults in page creation forms consistent
> ----------------------------------------------------------
>
>                 Key: GTNPORTAL-3470
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3470
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.0.Final
>
>
> This is a followup of the rejected GTNPORTAL-3459 which asked for applying move*Permission defaults from parent site. The present aim is to ensure for all page creation forms, that they use consistent defaults for all kinds of permissions.
> The page creation forms for which this applies:
> I. Page Creation Wizard accessible via Toolbar > Site Editor > Add New Page 
> II. New Page accessible via Toolbar > Group > Administration > Page Management > Add New Page
> III. Create Page accessible via Toolbar > Manage Sites > Edit Navigation > Create Node > Page Selector > Create Page
> For each of them, the defaults should be set as follows: 
> (1) For portal pages the access and edit permissions should be taken from the parent site.
> (2) For group pages, the the default access permissions should be set to all group members and edit should be set only to the given group's members with the membership type defined in {{navigation.creator.membership.type}} configuration parameter of {{UserACL}} service.
> (3) For any kind of page (portal, group, etc.), the move*Permissions form defaults are taken over form the {{page.xml}} template chosen in the given form. If the given form offers no page template choice, the {{empty}} template should be used.
> In the present implementation, the named requirements are mostly met, however the code is spread over several classes, and is not always 100% consistent, which should hereby be fixed.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 22:02:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Thu, 5 Jun 2014 22:02:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3486) Redirect to /sso
 instead of /login when SSO is enabled
In-Reply-To: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541214.1400578046000.20627.1402020135516@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran reassigned GTNPORTAL-3486:
-------------------------------------

    Assignee: Trong Tran  (was: Tuyen Nguyen The)


> Redirect to /sso instead of /login when SSO is enabled
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3486
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3486
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Trong Tran
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> When i configure SPNEGO SSO for Gatein,
> It work ok when i login with "login" link at top navigation bar. But when i try to access to page that rerquire login, (for example http://server.local.network:8080/portal/g/:platform:administrators/administration/registry), it will redirect to /login and i will not be logged in automatically with SPNEGO because spnego only work when it redirect to /dologin
> I think when SSO is enabled, we should redirect to /sso instead of /login when user try to access page that require login, then SSO will redirect to loginURL which was configured. 
> It's similar that we change link of "login" at top navigation bar to /sso when SSO is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Thu Jun  5 22:12:15 2014
From: issues at jboss.org (Takayuki Konishi (JIRA))
Date: Thu, 5 Jun 2014 22:12:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot
 decode surrogate pair characters
In-Reply-To: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542903.1401963673000.20628.1402020735253@jira02.app.mwc.hst.phx2.redhat.com>


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

Takayuki Konishi updated GTNCOMMON-24:
--------------------------------------

    Description: 
FastURLDecoder cannot decode surrogate pair characters.

When I decoded [U+20000B|http://www.fileformat.info/info/unicode/char/2000B/index.htm], I got MalformedInputException:
{code}
org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
{code}
I also attach a patch for testcase.

  was:
FastURLDecoder cannot decode surrogate pair characters.

When I decoded U+20000B, I got MalformedInputException:
{code}
org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
{code}
I also attach a patch for testcase.



> FastURLDecoder cannot decode surrogate pair characters
> ------------------------------------------------------
>
>                 Key: GTNCOMMON-24
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-24
>             Project: GateIn Common
>          Issue Type: Bug
>            Reporter: Takayuki Konishi
>         Attachments: surrogatepairtest.patch
>
>
> FastURLDecoder cannot decode surrogate pair characters.
> When I decoded [U+20000B|http://www.fileformat.info/info/unicode/char/2000B/index.htm], I got MalformedInputException:
> {code}
> org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
> 	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
> 	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
> {code}
> I also attach a patch for testcase.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 02:50:15 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Fri, 6 Jun 2014 02:50:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3507) Update test case from
 PLIDM-46 to gatein-portal test case
In-Reply-To: <JIRA.12543006.1402037371438@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543006.1402037371438@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543006.1402037371438.20882.1402037415289@jira02.app.mwc.hst.phx2.redhat.com>

Tran Trung Thanh created GTNPORTAL-3507:
-------------------------------------------

             Summary: Update test case from PLIDM-46 to gatein-portal test case
                 Key: GTNPORTAL-3507
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3507
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
    Affects Versions: 3.5.10.Final
            Reporter: Tran Trung Thanh


PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base  



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 02:54:15 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Fri, 6 Jun 2014 02:54:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3507) Update test case from
 PLIDM-46 to gatein-portal code base
In-Reply-To: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543006.1402037371000.20885.1402037655311@jira02.app.mwc.hst.phx2.redhat.com>


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

Tran Trung Thanh updated GTNPORTAL-3507:
----------------------------------------

    Summary: Update test case from PLIDM-46 to gatein-portal code base  (was: Update test case from PLIDM-46 to gatein-portal test case)


> Update test case from PLIDM-46 to gatein-portal code base
> ---------------------------------------------------------
>
>                 Key: GTNPORTAL-3507
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3507
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base  



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 03:24:15 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Fri, 6 Jun 2014 03:24:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3507) Update test case from
 PLIDM-46 to gatein-portal code base
In-Reply-To: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543006.1402037371000.20925.1402039455230@jira02.app.mwc.hst.phx2.redhat.com>


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

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

PR for gatein 3.5.x: https://github.com/gatein/gatein-portal/pull/873

> Update test case from PLIDM-46 to gatein-portal code base
> ---------------------------------------------------------
>
>                 Key: GTNPORTAL-3507
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3507
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>
> PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base  



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 04:08:16 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 6 Jun 2014 04:08:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3486) Redirect to /sso
 instead of /login when SSO is enabled
In-Reply-To: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541214.1400578046000.21019.1402042096043@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3486:
----------------------------------

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


> Redirect to /sso instead of /login when SSO is enabled
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3486
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3486
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> When i configure SPNEGO SSO for Gatein,
> It work ok when i login with "login" link at top navigation bar. But when i try to access to page that rerquire login, (for example http://server.local.network:8080/portal/g/:platform:administrators/administration/registry), it will redirect to /login and i will not be logged in automatically with SPNEGO because spnego only work when it redirect to /dologin
> I think when SSO is enabled, we should redirect to /sso instead of /login when user try to access page that require login, then SSO will redirect to loginURL which was configured. 
> It's similar that we change link of "login" at top navigation bar to /sso when SSO is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 04:22:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Fri, 6 Jun 2014 04:22:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocal
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.21039.1402042935868@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The reassigned GTNPORTAL-3499:
-------------------------------------------

    Assignee: Tuyen Nguyen The


> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocal
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 04:24:16 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Fri, 6 Jun 2014 04:24:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocal
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.21043.1402043056202@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on GTNPORTAL-3499 started by Tuyen Nguyen The.

> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocal
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 04:24:16 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Fri, 6 Jun 2014 04:24:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded
 English labels in Title and Field Name
In-Reply-To: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541834.1401072946000.21045.1402043056450@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The updated GTNPORTAL-3491:
----------------------------------------

              Status: Pull Request Sent  (was: Coding In Progress)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/874


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 06:10:15 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Fri, 6 Jun 2014 06:10:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocol
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.21373.1402049415740@jira02.app.mwc.hst.phx2.redhat.com>


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

Tran Trung Thanh updated GTNPORTAL-3499:
----------------------------------------

    Summary: Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocol  (was: Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocal)


> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocol
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 06:16:19 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 6 Jun 2014 06:16:19 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3486) Redirect to /sso
 instead of /login when SSO is enabled
In-Reply-To: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541214.1400578046000.21384.1402049779446@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3486:
----------------------------------

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


> Redirect to /sso instead of /login when SSO is enabled
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3486
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3486
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>  Remaining Estimate: 4 hours
>
> When i configure SPNEGO SSO for Gatein,
> It work ok when i login with "login" link at top navigation bar. But when i try to access to page that rerquire login, (for example http://server.local.network:8080/portal/g/:platform:administrators/administration/registry), it will redirect to /login and i will not be logged in automatically with SPNEGO because spnego only work when it redirect to /dologin
> I think when SSO is enabled, we should redirect to /sso instead of /login when user try to access page that require login, then SSO will redirect to loginURL which was configured. 
> It's similar that we change link of "login" at top navigation bar to /sso when SSO is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 06:16:19 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 6 Jun 2014 06:16:19 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3486) Redirect to /sso
 instead of /login when SSO is enabled
In-Reply-To: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541214.1400578046000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541214.1400578046000.21387.1402049779692@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3486?focusedWorklogId=12431305&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12431305 ]

Trong Tran logged work on GTNPORTAL-3486:
-----------------------------------------

                Author: Trong Tran
            Created on: 06/Jun/14 6:15 AM
            Start Date: 06/Jun/14 6:15 AM
    Worklog Time Spent: 4 hours 

Issue Time Tracking
-------------------

    Remaining Estimate: 0 minutes  (was: 4 hours)
            Time Spent: 4 hours
            Worklog Id:     (was: 12431305)


> Redirect to /sso instead of /login when SSO is enabled
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3486
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3486
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Tuyen Nguyen The
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>          Time Spent: 4 hours
>  Remaining Estimate: 0 minutes
>
> When i configure SPNEGO SSO for Gatein,
> It work ok when i login with "login" link at top navigation bar. But when i try to access to page that rerquire login, (for example http://server.local.network:8080/portal/g/:platform:administrators/administration/registry), it will redirect to /login and i will not be logged in automatically with SPNEGO because spnego only work when it redirect to /dologin
> I think when SSO is enabled, we should redirect to /sso instead of /login when user try to access page that require login, then SSO will redirect to loginURL which was configured. 
> It's similar that we change link of "login" at top navigation bar to /sso when SSO is enabled. 



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 06:18:15 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 6 Jun 2014 06:18:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-24) FastURLDecoder cannot
 decode surrogate pair characters
In-Reply-To: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542903.1401963673000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542903.1401963673000.21390.1402049895567@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNCOMMON-24:
---------------------------------------------

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


> FastURLDecoder cannot decode surrogate pair characters
> ------------------------------------------------------
>
>                 Key: GTNCOMMON-24
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-24
>             Project: GateIn Common
>          Issue Type: Bug
>            Reporter: Takayuki Konishi
>         Attachments: surrogatepairtest.patch
>
>
> FastURLDecoder cannot decode surrogate pair characters.
> When I decoded [U+20000B|http://www.fileformat.info/info/unicode/char/2000B/index.htm], I got MalformedInputException:
> {code}
> org.gatein.common.text.MalformedInputException: Cannot decode char 'A0'
> 	at org.gatein.common.text.FastURLDecoder.safeEncode(FastURLDecoder.java:217)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:45)
> 	at org.gatein.common.text.AbstractCharEncoder.encode(AbstractCharEncoder.java:62)
> 	at org.gatein.common.text.FastURLDecoderTestCase.testEncodeSurrogatePair(FastURLDecoderTestCase.java:159)
> {code}
> I also attach a patch for testcase.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Fri Jun  6 16:18:16 2014
From: issues at jboss.org (=?UTF-8?Q?L=C3=A1szl=C3=B3_van_den_Hoek_=28JIRA=29?=)
Date: Fri, 6 Jun 2014 16:18:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-1805) add ability to send
 email on registration and x successive failures
In-Reply-To: <JIRA.12430761.1297971016000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12430761.1297971016000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12430761.1297971016000.23453.1402085896601@jira02.app.mwc.hst.phx2.redhat.com>


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

L?szl? van den Hoek commented on GTNPORTAL-1805:
------------------------------------------------

Does WCI cover the REST API ({{/portal/rest/sso/authcallback/auth/_username_/_password_}})? I've looked at http://anonsvn.jboss.org/repos/gatein/components/wci/trunk/wci/src/main/doc/wci-authentication.pdf but it seems to me the answer is "no". So, in order to count calls to aforementioned REST URL where the return value is {{false}}, it seems to me {{UserDaoImpl.authenticate(username, password)}} would be the best place to register failed login attempts, much in the same way that {{User.setLastLoginTime(_now_)}} is called after succesful authentication.

You could then expand {{org.exoplatform.services.organization.UserEventListener}} with the methods {{preAuthenticate(User user)}} and {{postAuthenticate(User user, boolean success}}, and trigger these at the start and end of {{authenticate}}. Then you could do any logic like sending mail or blocking the user in the listener, and developers would be able to easily extend this functionality.

> add ability to send email on registration and x successive failures
> -------------------------------------------------------------------
>
>                 Key: GTNPORTAL-1805
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-1805
>             Project: GateIn Portal
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>            Reporter: Prabhat Jha
>            Assignee: Marek Posolda
>            Priority: Optional
>             Fix For: 3.9.0.Final
>
>         Attachments: README.txt, sendMailAfterInvalidLoginPatch.txt, sendMailAfterRegistrationPatch.txt
>
>
> Please attach the patch based on your work at https://issues.jboss.org/browse/JBQA-4122. By default the feature should be turned off.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Sun Jun  8 21:34:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Sun, 8 Jun 2014 21:34:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3491) [Gadget] Hard-coded
 English labels in Title and Field Name
In-Reply-To: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541834.1401072946000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541834.1401072946000.23937.1402277655494@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3491?focusedWorklogId=12431306&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12431306 ]

Tuyen Nguyen The logged work on GTNPORTAL-3491:
-----------------------------------------------

                Author: Tuyen Nguyen The
            Created on: 08/Jun/14 9:32 PM
            Start Date: 05/Jun/14 9:32 PM
    Worklog Time Spent: 6 hours 

Issue Time Tracking
-------------------

    Remaining Estimate: 0 minutes  (was: 4 hours)
            Time Spent: 6 hours
            Worklog Id:     (was: 12431306)


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Sun Jun  8 21:58:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Sun, 8 Jun 2014 21:58:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocol
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.23941.1402279095729@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The commented on GTNPORTAL-3499:
---------------------------------------------

This is caused by apache 2 configuration, apache proxy will pass the Host is the hostname specified in the ProxyPass line by default.

When i configure apache proxy follow the guideline at http://docs.exoplatform.com/public/index.jsp?topic=%2FPLF40%2FPLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
This method always returns http://localhost:8080/...
{code}
HttpServletRequest#getRequestURL()
{code}

After i add this configuration to apache proxy:
{code}
ProxyPreserveHost On
{code}
everything become ok.

So, to fix this issue, we have to turn on option ProxyPreserveHost in apache proxy configuration.



> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocol
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 6 hours
>  Remaining Estimate: 6 hours
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Sun Jun  8 21:58:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Sun, 8 Jun 2014 21:58:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocol
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.23943.1402279095849@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3499?focusedWorklogId=12431307&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12431307 ]

Tuyen Nguyen The logged work on GTNPORTAL-3499:
-----------------------------------------------

                Author: Tuyen Nguyen The
            Created on: 08/Jun/14 9:58 PM
            Start Date: 08/Jun/14 9:57 PM
    Worklog Time Spent: 2 hours 

Issue Time Tracking
-------------------

    Remaining Estimate: 0 minutes  (was: 6 hours)
            Time Spent: 2 hours
            Worklog Id:     (was: 12431307)


> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocol
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 6 hours
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Sun Jun  8 22:54:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Sun, 8 Jun 2014 22:54:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3477) Make GadgetImporter
 throw an exception with a meaningful message
In-Reply-To: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540360.1399651321000.23949.1402282455326@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong reassigned GTNPORTAL-3477:
-----------------------------------------

    Assignee: Vu Viet Phuong


> Make GadgetImporter throw an exception with a meaningful message
> ----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3477
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3477
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Vu Viet Phuong
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> {{GadgetImporter}} throws {{new IOException()}} without message and logs {{"Cannot import gadget " + gadgetURI + " because its data could not be found"}} on the previous line. We should apply both of the following:
> (1) Either throw or log not both
> (2) Throw exceptions with informative messages.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Sun Jun  8 22:54:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Sun, 8 Jun 2014 22:54:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3477) Make GadgetImporter
 throw an exception with a meaningful message
In-Reply-To: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540360.1399651321000.23951.1402282455406@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on GTNPORTAL-3477 started by Vu Viet Phuong.

> Make GadgetImporter throw an exception with a meaningful message
> ----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3477
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3477
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Vu Viet Phuong
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> {{GadgetImporter}} throws {{new IOException()}} without message and logs {{"Cannot import gadget " + gadgetURI + " because its data could not be found"}} on the previous line. We should apply both of the following:
> (1) Either throw or log not both
> (2) Throw exceptions with informative messages.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Sun Jun  8 23:00:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Sun, 8 Jun 2014 23:00:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3490) [Services Management
 gadget] Hard-coded English labels
In-Reply-To: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541833.1401072516000.23953.1402282815410@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3490:
----------------------------------

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


> [Services Management gadget] Hard-coded English labels
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3490
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3490
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.5.10.Final, 3.7.1.Final
>            Reporter: H. Trang Vu
>            Assignee: H. Trang Vu
>             Fix For: 3.7.2.Final, 3.9.0.Final
>
>         Attachments: FR-LargeSize-Methods-Properties.png, FR-Properties.png
>
>   Original Estimate: 1 hour
>  Remaining Estimate: 1 hour
>
> Steps to reproduce:
> * Login as root
> * Go to Application Registry, add *Services Management* gadget into a category
> * Open Dashboard
> * Add *Services Management* gadget
> * Switch to French. 
> * Open the gadget in both normal size and large size
> ** "Methods", "Properties" are still in English.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  9 00:06:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Mon, 9 Jun 2014 00:06:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3477) Make GadgetImporter
 throw an exception with a meaningful message
In-Reply-To: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540360.1399651321000.23959.1402286775394@jira02.app.mwc.hst.phx2.redhat.com>


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

Work on GTNPORTAL-3477 stopped by Vu Viet Phuong.

> Make GadgetImporter throw an exception with a meaningful message
> ----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3477
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3477
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Vu Viet Phuong
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> {{GadgetImporter}} throws {{new IOException()}} without message and logs {{"Cannot import gadget " + gadgetURI + " because its data could not be found"}} on the previous line. We should apply both of the following:
> (1) Either throw or log not both
> (2) Throw exceptions with informative messages.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  9 00:28:15 2014
From: issues at jboss.org (Vu Viet Phuong (JIRA))
Date: Mon, 9 Jun 2014 00:28:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3477) Make GadgetImporter
 throw an exception with a meaningful message
In-Reply-To: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540360.1399651321000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540360.1399651321000.23985.1402288095289@jira02.app.mwc.hst.phx2.redhat.com>


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

Vu Viet Phuong resolved GTNPORTAL-3477.
---------------------------------------

    Resolution: Done


> Make GadgetImporter throw an exception with a meaningful message
> ----------------------------------------------------------------
>
>                 Key: GTNPORTAL-3477
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3477
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Vu Viet Phuong
>   Original Estimate: 2 hours
>  Remaining Estimate: 2 hours
>
> {{GadgetImporter}} throws {{new IOException()}} without message and logs {{"Cannot import gadget " + gadgetURI + " because its data could not be found"}} on the previous line. We should apply both of the following:
> (1) Either throw or log not both
> (2) Throw exceptions with informative messages.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Mon Jun  9 02:02:15 2014
From: issues at jboss.org (H. Trang Vu (JIRA))
Date: Mon, 9 Jun 2014 02:02:15 -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.24004.1402293735622@jira02.app.mwc.hst.phx2.redhat.com>


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

H. Trang Vu commented on GTNPORTAL-3494:
----------------------------------------

[PR 862|https://github.com/gatein/gatein-portal/pull/862] has a side effect. *Application Name* field is read-only after its creation. It is now impossible to save (even without any change in Display Name, Description, Access Permission) any application because of *space* characters inside *Application Name*. The WARNING message is as follows.
{noformat}
Only letters, digits, dot, dash and underscore characters are allowed for the field "Application Name". 
{noformat}



> 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.3#6260)

From issues at jboss.org  Mon Jun  9 02:30:15 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 9 Jun 2014 02:30:15 -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.24034.1402295415510@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce commented on GTNPORTAL-3494:
----------------------------------------

Thanks for your comment. I'm going to review the patch and send a fix for this side effect.

> 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.3#6260)

From issues at jboss.org  Mon Jun  9 03:50:15 2014
From: issues at jboss.org (H. Trang Vu (JIRA))
Date: Mon, 9 Jun 2014 03:50:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3509) [Application
 Registry] Missing validator when importing applications
In-Reply-To: <JIRA.12543220.1402300153137@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543220.1402300153137@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543220.1402300153137.24154.1402300215503@jira02.app.mwc.hst.phx2.redhat.com>

H. Trang Vu created GTNPORTAL-3509:
--------------------------------------

             Summary: [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.8.2.Final, 3.7.1.Final, 3.5.10.Final
            Reporter: H. Trang Vu
            Priority: Minor


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.3#6260)

From issues at jboss.org  Mon Jun  9 04:06:15 2014
From: issues at jboss.org (H. Trang Vu (JIRA))
Date: Mon, 9 Jun 2014 04:06:15 -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.24228.1402301175933@jira02.app.mwc.hst.phx2.redhat.com>


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

H. Trang Vu updated GTNPORTAL-3509:
-----------------------------------

    Attachment: SiteRedirectsAndImportExportAdminPortlet-TooLongAppName-DisplayName.png


When importing automatically all applications, it only replaces slashes by underscores in Application Name and Display Name in [ApplicationRegistryServiceImpl.java|https://github.com/gatein/gatein-portal/blob/3.7.1.Final/component/application-registry/src/main/java/org/exoplatform/application/registry/impl/ApplicationRegistryServiceImpl.java#L382-L385]
{code:title=ApplicationRegistryServiceImpl.java}
            // Need to sanitize portlet and application names in case they contain characters that would
            // cause an improper Application name
            portletApplicationName = portletApplicationName.replace('/', '_');
            portletName = portletName.replace('/', '_');
{code}

While adding an application to a category on UI, it must pass the rule of length limit and character validation. For example, in [UIApplicationForm.java|https://github.com/gatein/gatein-portal/blob/3.7.1.Final/portlet/exoadmin/src/main/java/org/exoplatform/applicationregistry/webui/component/UIApplicationForm.java#L58-L61]
{code:title=UIApplicationForm.java}
    public UIApplicationForm() throws Exception {
        addUIFormInput(new UIFormStringInput("applicationName", "applicationName", null).addValidator(MandatoryValidator.class)
                .addValidator(StringLengthValidator.class, 3, 30).addValidator(NameValidator.class));
        addUIFormInput(new UIFormStringInput("displayName", "displayName", null).addValidator(StringLengthValidator.class, 3,
                30).addValidator(NotHTMLTagValidator.class));
        addUIFormInput(new UIFormTextAreaInput("description", "description", null).addValidator(NullFieldValidator.class)
                .addValidator(NotHTMLTagValidator.class));
    }
{code}

> [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
>            Priority: Minor
>         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.3#6260)

From issues at jboss.org  Mon Jun  9 04:24:15 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 9 Jun 2014 04:24:15 -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.24274.1402302255933@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3494:
-----------------------------------

              Status: Pull Request Sent  (was: Pull Request Sent)
    Git Pull Request: https://github.com/gatein/gatein-portal/pull/862, https://github.com/gatein/gatein-portal/pull/876  (was: https://github.com/gatein/gatein-portal/pull/862)


> 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.3#6260)

From issues at jboss.org  Mon Jun  9 04:26:16 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 9 Jun 2014 04:26:16 -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.24277.1402302376387@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce commented on GTNPORTAL-3494:
----------------------------------------

PR proposed and sent.

> 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.3#6260)

From issues at jboss.org  Mon Jun  9 04:44:15 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 9 Jun 2014 04:44:15 -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.24359.1402303455516@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce commented on GTNPORTAL-3509:
----------------------------------------

Hello,
I've prepared a fix for the side effect discovered on GTNPORTAL-3494.
This new issue is related to same code, I can take this JIRA and propose a fix if you are OK.

Please, let me know.

Thanks,
Lucas

> [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
>            Priority: Minor
>         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.3#6260)

From issues at jboss.org  Mon Jun  9 05:14:16 2014
From: issues at jboss.org (H. Trang Vu (JIRA))
Date: Mon, 9 Jun 2014 05:14:16 -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.24450.1402305256597@jira02.app.mwc.hst.phx2.redhat.com>


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

H. Trang Vu commented on GTNPORTAL-3509:
----------------------------------------

Thank you [~rutlucas]. It's OK if you include the fix for this issue in the same PR for GTNPORTAL-3494. The sanitization should be done for both category and application.

> [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
>            Priority: Minor
>         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.3#6260)

From issues at jboss.org  Mon Jun  9 05:20:16 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 9 Jun 2014 05:20:16 -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.24459.1402305616231@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce reassigned GTNPORTAL-3509:
--------------------------------------

    Assignee: Lucas Ponce


> [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
>         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.3#6260)

From issues at jboss.org  Mon Jun  9 06:58:15 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 9 Jun 2014 06:58:15 -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.24627.1402311495443@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3509:
-----------------------------------

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


> [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
>         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.3#6260)

From issues at jboss.org  Tue Jun 10 04:09:15 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Tue, 10 Jun 2014 04:09:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3490) [Services Management
 gadget] Hard-coded English labels
In-Reply-To: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541833.1401072516000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541833.1401072516000.26317.1402387755649@jira02.app.mwc.hst.phx2.redhat.com>


     [ https://issues.jboss.org/browse/GTNPORTAL-3490?focusedWorklogId=12431308&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-12431308 ]

Trong Tran logged work on GTNPORTAL-3490:
-----------------------------------------

                Author: Trong Tran
            Created on: 10/Jun/14 4:08 AM
            Start Date: 10/Jun/14 4:08 AM
    Worklog Time Spent: 1 hour 

Issue Time Tracking
-------------------

    Remaining Estimate: 0 minutes  (was: 1 hour)
            Time Spent: 1 hour
            Worklog Id:     (was: 12431308)


> [Services Management gadget] Hard-coded English labels
> ------------------------------------------------------
>
>                 Key: GTNPORTAL-3490
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3490
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Internationalization and Localization
>    Affects Versions: 3.5.10.Final, 3.7.1.Final
>            Reporter: H. Trang Vu
>            Assignee: H. Trang Vu
>             Fix For: 3.7.2.Final, 3.9.0.Final
>
>         Attachments: FR-LargeSize-Methods-Properties.png, FR-Properties.png
>
>   Original Estimate: 1 hour
>          Time Spent: 1 hour
>  Remaining Estimate: 0 minutes
>
> Steps to reproduce:
> * Login as root
> * Go to Application Registry, add *Services Management* gadget into a category
> * Open Dashboard
> * Add *Services Management* gadget
> * Switch to French. 
> * Open the gadget in both normal size and large size
> ** "Methods", "Properties" are still in English.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 04:13:15 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Tue, 10 Jun 2014 04:13:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3499) Result of Rest API
 contains original host when Gatein runs behind apache server via HTTP
 protocol
In-Reply-To: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542260.1401329432000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542260.1401329432000.26325.1402387995784@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The resolved GTNPORTAL-3499.
-----------------------------------------

    Resolution: Won't Fix


> Result of Rest API contains original host when Gatein runs behind apache server via HTTP protocol
> -------------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3499
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3499
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Tran Trung Thanh
>            Assignee: Tuyen Nguyen The
>   Original Estimate: 6 hours
>          Time Spent: 2 hours
>  Remaining Estimate: 0 minutes
>
> - Configure eXo Platform with apache 2 via HTTP protocol by following
> http://docs.exoplatform.com/public/topic/PLF40/PLFAdminGuide.Deployment.SetupApacheFrontend.ConnectViaHTTP.html
> - Start Gatein server at localhost:8080
> - Access Gatein service by using address of apache for example example.localhost
> - Login as john
> - Call REST API: http://example.localhost/rest/private/managed-components/mop/usersites/john/pages/Tab_Default
> -> The result contains the original host
> {noformat}
> {"description":"List of child pages for page 'Tab_Default'","children":[],"operations":[{"operation-name":"read-resource","operation-description":"Lists available pages at a specified address.","link":{"rel":"self","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default"}},{"operation-name":"read-config-as-xml","operation-description":"Reads pages as configuration xml at a specified address.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.xml","type":"application/xml"}},{"operation-name":"export-resource","operation-description":"Exports pages configuration xml as a zip file.","link":{"rel":"content","href":"http://localhost:8080/rest/private/managed-components/mop/usersites/john/pages/Tab_Default.zip","type":"application/zip","method":"get"}}]}
> {noformat}
> Note that: No problem when configuring apache front-end with ajp.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 04:37:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 04:37:16 -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.26372.1402389435996@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3494:
-----------------------------------------------

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


> 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.3#6260)

From issues at jboss.org  Tue Jun 10 04:45:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 04:45:16 -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.26398.1402389916350@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3509:
-----------------------------------------------

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


> [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
>         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.3#6260)

From issues at jboss.org  Tue Jun 10 04:47:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 04:47:16 -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.26407.1402390036217@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> [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
>         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.3#6260)

From issues at jboss.org  Tue Jun 10 04:47:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 04:47:16 -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.26409.1402390036553@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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.3#6260)

From issues at jboss.org  Tue Jun 10 05:27:15 2014
From: issues at jboss.org (Boubaker Khanfir (JIRA))
Date: Tue, 10 Jun 2014 05:27:15 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3110) IDM DAO classes are
 only catching IdentityExceptions
In-Reply-To: <JIRA.12493994.1370933249000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12493994.1370933249000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12493994.1370933249000.26487.1402392435659@jira02.app.mwc.hst.phx2.redhat.com>


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

Boubaker Khanfir commented on GTNPORTAL-3110:
---------------------------------------------

I think that we have a regression here. Any exception from IDM operations will cause a rollback without throwing an exception. That's what was fixed here:
GTNPORTAL-3243
IMO, we have to throw an exception at the end of "recoverFromIDMError" method.
Should I open a new issue for that ?
Fix Version should be for 3.5+

> IDM DAO classes are only catching IdentityExceptions
> ----------------------------------------------------
>
>                 Key: GTNPORTAL-3110
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3110
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.6.0.Beta02
>            Reporter: Martin Weiler
>            Assignee: Marek Posolda
>             Fix For: 3.6.0.Final
>
>
> In some IDM DAO classes, such as GroupDAOImpl, MembershipDAOImpl and UserProfileDAOImpl all IDM calls are wrapped with try..catch(Exception e) blocks, which ensures that not only IdentityException, but also Hibernate exceptions are caught and recovered with rollback().
> But in UserDAOImpl only "IdentityException e" instances are caught. So HibernateException are not handled, which can result in transaction errors. Additionally, in MembershipTypeDAOImpl the IDM calls are not wrapped with any catch blocks, which also needs to be fixed.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for
 JavaScript and skin services
In-Reply-To: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542445.1401481836000.27074.1402402156984@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema
 validation for gatein-resources.xml
In-Reply-To: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542441.1401478549000.27076.1402402157501@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-2581) RichFaces is not
 defined after adding a RF portlet to a page
In-Reply-To: <JIRA.12474884.1348062188000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474884.1348062188000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474884.1348062188000.27081.1402402157767@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> RichFaces is not defined after adding a RF portlet to a page
> ------------------------------------------------------------
>
>                 Key: GTNPORTAL-2581
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-2581
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: GateIn 3.4.0.Final
>            Reporter: Peter Palaga
>         Attachments: jsf2-rf4-hello-world-portlet.war
>
>
> (1) Start a fresh GateIn 3.4.0.Final:
> cd tmp
> wget http://downloads.jboss.org/gatein/Releases/Portal/3.4.0.Final/GateIn-3.4.0.Final-jbossas7.zip 
> unzip GateIn-3.4.0.Final-jbossas7.zip
> cd GateIn-3.4.0.Final-jbossas7/bin
> ./standalone.sh
> (2) Install gatein-bom-3.4
> git clone https://github.com/ppalaga/gatein-bom.github
> cd gatein-bom
> mvn install -Dgpg.skip=true
> (3) Pack and deploy jsf2-rf4-hello-world-portlet:
> cd tmp
> git clone https://github.com/ppalaga/gatein-portal-quickstart.git
> cd gatein-portal-quickstart/jsf2-rf4-hello-world-portlet
> mvn package jboss-as:deploy
> (4)  In web browser:
> * login as root http://127.0.0.1:8080/portal/login?username=root&password=gtn&initialURI=/portal/classic/
> (5) In web browser:
> * Group > Administration > Application Registry > Import Applications
> * Site > Classic > Home
> * Site Editor > Edit Page
> * Drag jsf2-rf4-hello-world-portlet and drop it e.g. under the Home Page portlet
> * make the console with server log visible to you
> * Open developer tools (F12 in Chrome) and switch to Resources. Have a look at loaded scripts. Note that there are no PBR-related scripts there.
> (6) Hit Finish (Diskette Icon) in Page Editor dialog
> (7) UNEXPECTED: After hitting Finish, there comes a modal message in the browser window saying "RichFaces is not defined". 
> * Note that while this message is being displayed, there is no change in the scripts compared to before (5).
> * Note that nothing happened in the server log.
>  
> (8) Hit OK in the "RichFaces is not defined" alert.
> * Note that one or more PBR-related scripts were loaded. Some of them have error markers in them
> * Sometimes one or more org.exoplatform.portal.config.NoSuchDataExceptions appear in the server log
>  
> The problem seems to be related to the fact that the inline JavaScript needed to render the rich:select component is evaluated before the needed js resources were loaded. After reloading the whole page or accessing the page from another session jsf2-rf4-hello-world-portlet works as expected. 
> For further observations, define one more step:
> (9)
> * Site > Classic > Home
> * Site Editor > Edit Page
> * remove jsf2-rf4-hello-world-portlet from the page
> * Hit Finish (Diskette Icon) in Page Editor dialog
> When in the state after (8), one performs (9) and then again (5) and (6), "RichFaces is not defined" does not appear.
> "RichFaces is not defined" appears only when one signs out from the portal and signs in again between (9) and (5) of the previous scenario.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:17 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3485) Add an option to load
 AMD JavaScript from a CDN
In-Reply-To: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541211.1400577402000.27078.1402402157600@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Add an option to load AMD JavaScript from a CDN
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3485
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3485
>             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
>
>




--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:17 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:17 -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.27083.1402402157934@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:18 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:18 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3484) Commit changes for a
 page before send response
In-Reply-To: <JIRA.12541206.1400575908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541206.1400575908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541206.1400575908000.27085.1402402158208@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Commit changes for a page before send response
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3484
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3484
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> In current design a call to RequestLifeCycle.end() is performed at the end of the request meanwhile a markup can be send it before with portlets ID not yet commited.
> This can cause some StaleModelException cases under heavy load or database congestion.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:18 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:18 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3497) Portlet in Dashboard
 is broken for the first access
In-Reply-To: <JIRA.12542102.1401266724000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542102.1401266724000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542102.1401266724000.27087.1402402158364@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

>  Portlet in Dashboard is broken for the first access
> ----------------------------------------------------
>
>                 Key: GTNPORTAL-3497
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3497
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> From BZ 1059036: 
> If you configure a richfaces portlet in dashboard template, the portlet may break for the first access by a newly created user.
> https://bugzilla.redhat.com/show_bug.cgi?id=1059036



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Tue Jun 10 08:09:18 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:18 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNMOP-54) Tests in WorkspaceTestCase
 are order dependent
In-Reply-To: <JIRA.12541101.1400497517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541101.1400497517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541101.1400497517000.27090.1402402158661@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on GTNMOP-54:
-----------------------------------------------

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

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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:18 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:18 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-21) Serialization of
 ParameterMap breaks with JBoss Marshalling
In-Reply-To: <JIRA.12530365.1390813730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530365.1390813730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530365.1390813730000.27093.1402402158887@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on GTNCOMMON-21:
--------------------------------------------------

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

> Serialization of ParameterMap breaks with JBoss Marshalling
> -----------------------------------------------------------
>
>                 Key: GTNCOMMON-21
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-21
>             Project: GateIn Common
>          Issue Type: Bug
>    Affects Versions: 2.1.1.Final
>         Environment: JPP 6.1.0
>            Reporter: Martin Weiler
>             Fix For: 2.2.0.Beta01, 2.1.2.Final
>
>
> Serialization of a ParameterMap instance with JBoss Marshalling (used by Infinispan) breaks with the following exception:
> {noformat}
> 15:20:33,853 ERROR [org.infinispan.marshall.VersionAwareMarshaller] (transport-thread-11) ISPN000065: Exception while marshalling object: java.io.NotActiveException: Fields were never written
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.finish(RiverObjectOutputStream.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1009)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.clustering.SimpleMarshalledValue.getBytes(SimpleMarshalledValue.java:85)
> 	at org.jboss.as.clustering.SimpleMarshalledValue.writeExternal(SimpleMarshalledValue.java:175)
> 	at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:47)
> 	at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:36)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ForeignExternalizerAdapter.writeObject(ExternalizerTable.java:459)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallMap(MarshallUtil.java:59)
> 	at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:63)
> 	at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:47)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:250)
> 	at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:247)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:154)
> 	at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:150)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:103)
> 	at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:88)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeCommandParameters(ReplicableCommandExternalizer.java:87)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.marshallParameters(CacheRpcCommandExternalizer.java:128)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:112)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:73)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:96)
> 	at org.infinispan.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:92)
> 	at org.infinispan.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:64)
> 	at org.infinispan.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:109)
> 	at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:45)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:279)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:300)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
> 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190)
> 	at org.infinispan.statetransfer.OutboundTransferTask.sendEntries(OutboundTransferTask.java:257)
> 	at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:187)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: an exception which occurred:
> 	in field parameters
> 	in field navigationalState
> 	in object java.util.HashMap at 7b2c68fe
> {noformat}
> The NotActiveException is a result of a broken writeObject implementation in org.gatein.common.util.ParameterMap, which does not call out.defaultWriteObject();



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:19 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:19 -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.27099.1402402159373@jira02.app.mwc.hst.phx2.redhat.com>


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

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.3#6260)


From issues at jboss.org  Tue Jun 10 08:09:19 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:19 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3475) NPE in
 LinkedList$ListItr.next when iterating over
 UIGroupMembershipSelect.getListMemberhip()
In-Reply-To: <JIRA.12540331.1399635695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540331.1399635695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540331.1399635695000.27101.1402402159564@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> NPE in LinkedList$ListItr.next when iterating over UIGroupMembershipSelect.getListMemberhip()
> ---------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3475
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3475
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>         Attachments: GTNPORTAL-3475.log
>
>
> Looks like a concurrent modification of  the {{LinkedList}} refered to by {{UIGroupMembershipSelect.listMemberhip}}, because:
> i. It is not always reproducible, the NPE occurs roughly once per 10 attempts.
> ii. It happens on line {{next = next.next}} of the JRE's {{LinkedList.ListItr}} where it is hard to thing of anything else than concurrent modification as a cause.
> Steps to reproduce:
> (1) Start clean Portal instance for the first time
> (2) Go to Application Registry
> (3) Import Applications
> Not OK: There is an NPE logged (the whole log is attached):
> {code:none}
> Caused by: java.lang.NullPointerException
> 	at java.util.LinkedList$ListItr.next(LinkedList.java:891) [rt.jar:1.7.0_55]
> 	at UIGroupMembershipSelector.run(UIGroupMembershipSelector.gtmpl:20)	at org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:99) [exo.portal.component.scripting-3.8.0.Beta02-SNAPSHOT.jar:3.8.0.Beta02-SNAPSHOT]
> 	at org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:115) [exo.portal.component.scripting-3.8.0.Beta02-SNAPSHOT.jar:3.8.0.Beta02-SNAPSHOT]
> {code}
> Expected: No NPE



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 08:09:19 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 08:09:19 -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.27103.1402402159681@jira02.app.mwc.hst.phx2.redhat.com>


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

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
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)


From issues at jboss.org  Tue Jun 10 08:59:16 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 10 Jun 2014 08:59:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3510) Possible memory leaks,
 consistency issues and concurrency issues in ScriptGraph
In-Reply-To: <JIRA.12543336.1402405130437@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543336.1402405130437@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543336.1402405130437.27288.1402405156120@jira02.app.mwc.hst.phx2.redhat.com>

Peter Palaga created GTNPORTAL-3510:
---------------------------------------

             Summary: Possible memory leaks, consistency issues and concurrency issues in ScriptGraph
                 Key: GTNPORTAL-3510
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3510
             Project: GateIn Portal
          Issue Type: Feature Request
      Security Level: Public (Everyone can see)
            Reporter: Peter Palaga
            Assignee: Peter Palaga


h4. Problems in the Present State
(1) Consitency: there are {{IllegalStateException}} s thrown when adding resources from a deployment. Those exceptions can be thrown in the middle of such an adding which can lead to an inconsistent state when resources from a particular deployment are partly there and partly not there in the {{ScriptGraph}}.
(2) Consitency: The present resource removal code does not ensure that a removed resource is also removed from dependent resources, closures and load groups. There are also no tests checking that.
(3) Possible leaks: closures and load groups are not cleaned upon resource removals which can lead to memory leaks. This is a consequence of (2). 
(4) Concurrency: add and remove operations manipulate directly with collection instances that can be read (e.g. via {{getResource()}}) concurrently from other threads. 

h4. Solution proposal
\(i) Make {{ScriptGraph}} immutable and always create a new instance (using some kind of builder pattern) when adding or removing resources. This should solve problems (1) and (4).
(ii) Improve the resource removal code to the effect that dependencies, closures and load groups are kept consistent upon removals. Add tests. This should solve problems (2) and (3).



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 09:51:16 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Tue, 10 Jun 2014 09:51:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher
 doesn't support IPv6 addresses
In-Reply-To: <JIRA.12543342.1402408197631@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543342.1402408197631@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543342.1402408197631.27520.1402408276237@jira02.app.mwc.hst.phx2.redhat.com>

Lucas Ponce created GTNPORTAL-3511:
--------------------------------------

             Summary: BasicHttpFetcher doesn't support IPv6 addresses
                 Key: GTNPORTAL-3511
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3511
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Shindig
    Affects Versions: 3.8.2.Final
            Reporter: Lucas Ponce
            Assignee: Lucas Ponce
             Fix For: 3.9.0.Final


BasicHttpFetcher.java cannot process IPv6 with format [::1].

Some logic like this:

    String[] hostparts = StringUtils.splitPreserveAllTokens(uri.getAuthority(),':');
    int port = -1; // default port
    if (hostparts.length > 2) {
      throw new GadgetException(GadgetException.Code.INVALID_USER_DATA,
          "Bad host name in request: " + uri.getAuthority(),
          HttpServletResponse.SC_BAD_REQUEST);
    }

has to be updated to support IPv4 and IPv6 formats.



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 09:51:16 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 10 Jun 2014 09:51:16 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher
 doesn't support IPv6 addresses
In-Reply-To: <JIRA.12543342.1402408197000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543342.1402408197000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543342.1402408197000.27522.1402408276495@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3511:
-----------------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Tue Jun 10 11:47:15 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 10 Jun 2014 11:47:15 -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.27795.1402415235313@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3506:
------------------------------------

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


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



--
This message was sent by Atlassian JIRA
(v6.2.3#6260)

From issues at jboss.org  Wed Jun 11 07:39:46 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 11 Jun 2014 07:39:46 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNMOP-54) Tests in WorkspaceTestCase
 are order dependent
In-Reply-To: <JIRA.12541101.1400497517000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541101.1400497517000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541101.1400497517000.86.1402486786646@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on GTNMOP-54:
-----------------------------------------------

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

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



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

From issues at jboss.org  Wed Jun 11 16:48:37 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 11 Jun 2014 16:48:37 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3510) Possible memory leaks,
 consistency issues and concurrency issues in ScriptGraph
In-Reply-To: <JIRA.12543336.1402405130000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543336.1402405130000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543336.1402405130000.2191.1402519717828@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3510:
------------------------------------

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


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



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

From issues at jboss.org  Thu Jun 12 16:15:42 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Thu, 12 Jun 2014 16:15:42 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher
 doesn't support IPv6 addresses
In-Reply-To: <JIRA.12543342.1402408197000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543342.1402408197000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543342.1402408197000.5024.1402604142726@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3511:
-----------------------------------

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


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



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

From issues at jboss.org  Fri Jun 13 06:01:47 2014
From: issues at jboss.org (Boubaker Khanfir (JIRA))
Date: Fri, 13 Jun 2014 06:01:47 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3512) Don't swallow
 exception when happens on IDM API
In-Reply-To: <JIRA.12543722.1402653655439@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543722.1402653655439@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543722.1402653655439.5820.1402653707839@jira02.app.mwc.hst.phx2.redhat.com>

Boubaker Khanfir created GTNPORTAL-3512:
-------------------------------------------

             Summary: Don't swallow exception when happens on IDM API
                 Key: GTNPORTAL-3512
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3512
             Project: GateIn Portal
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
    Affects Versions: 3.8.2.Final, 3.7.1.Final, 3.6.3.Final, 3.5.10.Final
            Reporter: Boubaker Khanfir


The GateIN IDM implementation is a Data Management Layer Impl. Thus, the exceptions and errors occurred in this level have to be thrown to upper layer. In fact, if we see what is done in "recoverFromIDMError", we see that no exception is thrown after "rollback" operation is done.
Let's take a simple example for this use case:
I have an API that :

# create a user.
# create a group.
# assign the user to this group.
# do some other initialization tasks for that user.

If, for example, I got an error in User creation operation, I will not be able to "break" the complete operation. As workaround, I have to do the "findUserByName", but this is not normal, because if the "saveUser" operation fails, it should throw an exception so that I can handle it.

The modification in GateIN source code is simple: just add a "throw exception" at the end of "recoverFromIDMError" method.



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

From issues at jboss.org  Fri Jun 13 06:15:40 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 06:15:40 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-38) Export / Import
In-Reply-To: <JIRA.12541420.1400689767000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541420.1400689767000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541420.1400689767000.5851.1402654540900@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce resolved GTNWCM-38.
-------------------------------

    Fix Version/s: 2.x
       Resolution: Done


> Export / Import
> ---------------
>
>                 Key: GTNWCM-38
>                 URL: https://issues.jboss.org/browse/GTNWCM-38
>             Project: GateIn WCM
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 2.x
>
>
> Add a export / import tool that can handle content in a bundle.



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

From issues at jboss.org  Fri Jun 13 06:15:41 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 06:15:41 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-39) Tag version 2.1.0
In-Reply-To: <JIRA.12543723.1402654473544@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543723.1402654473544@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543723.1402654473544.5855.1402654541139@jira02.app.mwc.hst.phx2.redhat.com>

Lucas Ponce created GTNWCM-39:
---------------------------------

             Summary: Tag version 2.1.0
                 Key: GTNWCM-39
                 URL: https://issues.jboss.org/browse/GTNWCM-39
             Project: GateIn WCM
          Issue Type: Enhancement
      Security Level: Public (Everyone can see)
            Reporter: Lucas Ponce






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

From issues at jboss.org  Fri Jun 13 06:39:37 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 06:39:37 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-39) Tag version 2.1.0
In-Reply-To: <JIRA.12543723.1402654473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543723.1402654473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543723.1402654473000.5933.1402655977812@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce reassigned GTNWCM-39:
---------------------------------

    Assignee: Lucas Ponce


> Tag version 2.1.0
> -----------------
>
>                 Key: GTNWCM-39
>                 URL: https://issues.jboss.org/browse/GTNWCM-39
>             Project: GateIn WCM
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>




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

From issues at jboss.org  Fri Jun 13 06:45:40 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 13 Jun 2014 06:45:40 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3507) Update test case from
 PLIDM-46 to gatein-portal code base
In-Reply-To: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543006.1402037371000.5937.1402656340684@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3507:
----------------------------------

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


> Update test case from PLIDM-46 to gatein-portal code base
> ---------------------------------------------------------
>
>                 Key: GTNPORTAL-3507
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3507
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>
> PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base  



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

From issues at jboss.org  Fri Jun 13 06:45:41 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 13 Jun 2014 06:45:41 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764000.5946.1402656341858@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran commented on GTNPORTAL-3504:
---------------------------------------

committed on 3.5.x and 3.7.x branches

> Upgrade Picketlink IDM to 1.4.5.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3504
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.1.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             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  Fri Jun 13 06:45:42 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 13 Jun 2014 06:45:42 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3507) Update test case from
 PLIDM-46 to gatein-portal code base
In-Reply-To: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543006.1402037371000.5948.1402656342084@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran resolved GTNPORTAL-3507.
-----------------------------------

    Resolution: Done


> Update test case from PLIDM-46 to gatein-portal code base
> ---------------------------------------------------------
>
>                 Key: GTNPORTAL-3507
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3507
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>
> PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base  



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

From issues at jboss.org  Fri Jun 13 07:52:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 07:52:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-39) Tag version 2.1.0
In-Reply-To: <JIRA.12543723.1402654473000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543723.1402654473000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543723.1402654473000.6129.1402660358023@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce resolved GTNWCM-39.
-------------------------------

    Resolution: Done


> Tag version 2.1.0
> -----------------
>
>                 Key: GTNWCM-39
>                 URL: https://issues.jboss.org/browse/GTNWCM-39
>             Project: GateIn WCM
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>




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

From issues at jboss.org  Fri Jun 13 08:24:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:24:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-375) Missing app icon
In-Reply-To: <JIRA.12536642.1396279371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536642.1396279371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536642.1396279371000.6203.1402662278426@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNWSRP-375:
--------------------------------

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


> Missing app icon
> ----------------
>
>                 Key: GTNWSRP-375
>                 URL: https://issues.jboss.org/browse/GTNWSRP-375
>             Project: GateIn WSRP
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Juraci Paix?o Kr?hling
>
> Wsrp admin gui has not icon for app registry in gatein.



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


From issues at jboss.org  Fri Jun 13 08:26:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:26:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3435) Import .zip REST API
 broken with EAP 6.3.0.Alpha1
In-Reply-To: <JIRA.12536480.1396020937000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536480.1396020937000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536480.1396020937000.6207.1402662398192@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce resolved GTNPORTAL-3435.
------------------------------------

    Resolution: Done


> Import .zip REST API broken with EAP 6.3.0.Alpha1
> -------------------------------------------------
>
>                 Key: GTNPORTAL-3435
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3435
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>         Attachments: jbossweb-7.4.1.Final.jar, portal_classic_2014-03-28_16-59-29.zip
>
>
> A curl operation over template/user API:
> curl -i -H "Content-Type: application/zip" -u root:gtn -X PUT -T examples/user.zip "http://localhost:8080/rest/private/managed-components/template/user"
> hangs with:
> 16:35:16,466 INFO  [org.exoplatform.portal.mop.management.operations.TemplateImportResource] (http-/127.0.0.1:8080-4) Import successful !
> 16:35:16,475 ERROR [org.apache.catalina.connector] (http-/127.0.0.1:8080-4) JBWEB001018: An exception or error occurred in the container during the request processing: java.nio.BufferOverflowException
>         at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:357) [rt.jar:1.7.0_25]
>         at org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:666) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProcessor.commit(Http11NioProcessor.java:480) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:798) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.Response.action(Response.java:190) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.Response.sendHeaders(Response.java:390) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:352) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:318) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.Response.finishResponse(Response.java:487) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:371) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:353) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:911) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:920) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]



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

From issues at jboss.org  Fri Jun 13 08:28:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:28:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3464) Enabled/disabled
	users icons
In-Reply-To: <JIRA.12539420.1398861037000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12539420.1398861037000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539420.1398861037000.6208.1402662518244@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3464:
-----------------------------------

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


> Enabled/disabled users icons
> ----------------------------
>
>                 Key: GTNPORTAL-3464
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3464
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.0.Beta01
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.0.Final, 3.9.0.Final
>
>
> Enabled users have a grey icon and disable users have a green icon in users admin app.
> This create some confusion at UI as expected behaviour colors are the opposity.
> A good solution for that would be to update the column title
> ?Enabled? to ?Status?. Also, with this kind of label, the icon must indicate
> the current status. So, grey icon for disabled and green icon for enabled.
> The tooltip also must indicate the current status, so it should say
> ?Disabled User? for gray icons and ?Enabled User? for green icons.
>  
> When the user clicks on the icon, it should change for the opposite, and the text in the tooltip should be updated.



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


From issues at jboss.org  Fri Jun 13 08:30:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:30:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3480) Upgrade WCI
	dependency to 2.4.2.Final
In-Reply-To: <JIRA.12540610.1399972559000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540610.1399972559000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540610.1399972559000.6211.1402662638003@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce resolved GTNPORTAL-3480.
------------------------------------

      Assignee: Lucas Ponce
    Resolution: Done


> Upgrade WCI dependency to 2.4.2.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3480
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3480
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>




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

From issues at jboss.org  Fri Jun 13 08:32:37 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:32:37 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWSRP-374) Improve admin GUI to be
	W3C compliant
In-Reply-To: <JIRA.12534405.1394200477000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12534405.1394200477000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12534405.1394200477000.6215.1402662757961@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNWSRP-374:
--------------------------------

           Status: Resolved  (was: Pull Request Sent)
    Fix Version/s: 2.3.0
       Resolution: Done


> Improve admin GUI to be W3C compliant
> -------------------------------------
>
>                 Key: GTNWSRP-374
>                 URL: https://issues.jboss.org/browse/GTNWSRP-374
>             Project: GateIn WSRP
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Admin GUI
>    Affects Versions: 2.2.11.Final
>            Reporter: Lucas Ponce
>            Assignee: Juraci Paix?o Kr?hling
>             Fix For: 2.2.12.Final, 2.3.0
>
>
> Admin GUI portlet has some issues incompatible with XHTML 1.0 spec:
> - <link> tags rendered inside <body> tags.
> - Repeated id attributes in generated JSF tags.
> - Other minor enhancenemtns.



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


From issues at jboss.org  Fri Jun 13 08:32:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:32:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCI-52) Release 2.4.2.Final
In-Reply-To: <JIRA.12540611.1399972655000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540611.1399972655000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540611.1399972655000.6216.1402662758026@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce resolved GTNWCI-52.
-------------------------------

    Resolution: Done


> Release 2.4.2.Final
> -------------------
>
>                 Key: GTNWCI-52
>                 URL: https://issues.jboss.org/browse/GTNWCI-52
>             Project: GateIn Web Container Integration
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>




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

From issues at jboss.org  Fri Jun 13 08:32:38 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Fri, 13 Jun 2014 08:32:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-2856) Remove all default
 users besides admin.
In-Reply-To: <JIRA.12487725.1363880343000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12487725.1363880343000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12487725.1363880343000.6217.1402662758109@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce closed GTNPORTAL-2856.
----------------------------------

    Resolution: Done


> Remove all default users besides admin.
> ---------------------------------------
>
>                 Key: GTNPORTAL-2856
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-2856
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>




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

From issues at jboss.org  Fri Jun 13 09:34:38 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Jun 2014 09:34:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3454) Remove native AMD
 modules from requireJs config
In-Reply-To: <JIRA.12538878.1398255088000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12538878.1398255088000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12538878.1398255088000.6372.1402666478230@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Remove native AMD modules from requireJs config
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3454
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3454
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.0.Final
>
>
> RequireJs config is a json structure renderead inline in the HTML markup of every page returned by the portal. The recent "Native AMD Support" feature has brought the possibility to work with large third-party javascript frameworks such as Dojo containing thousands of JavaScript modules. The present implementation adds an entry for every native AMD module into RequireJs config. With a dojo portlet deployed, this causes an overhead of more than 400KB per page.
> Steps to Reproduce:
> 1. Compile and deploy the dojo portlet application from https://github.com/ppalaga/dojo-portlet
> 2. Import applications
> 3. Inspect the source of any portal page, e.g. /portal/classic/home
> 4. Locate the line starting with
>   var require =
> Actual results: All dojo resources are there in the json structure assigned to the require variable.
> Expected results: No resources coming from Dojo should be there.
> Additional info: Not having the resources coming from Dojo in requireJS config is technically possible as the native AMD modules are implicitly SHARED and the baseUrl is set properly in the config.



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

From issues at jboss.org  Fri Jun 13 10:10:37 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Jun 2014 10:10:37 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3497) Portlet in Dashboard
 is broken for the first access
In-Reply-To: <JIRA.12542102.1401266724000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542102.1401266724000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542102.1401266724000.6520.1402668637873@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

>  Portlet in Dashboard is broken for the first access
> ----------------------------------------------------
>
>                 Key: GTNPORTAL-3497
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3497
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>
> From BZ 1059036: 
> If you configure a richfaces portlet in dashboard template, the portlet may break for the first access by a newly created user.
> https://bugzilla.redhat.com/show_bug.cgi?id=1059036



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


From issues at jboss.org  Fri Jun 13 13:46:38 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 13 Jun 2014 13:46:38 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema
 validation for gatein-resources.xml
In-Reply-To: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542441.1401478549000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542441.1401478549000.7317.1402681598011@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

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



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

From issues at jboss.org  Mon Jun 16 04:47:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Mon, 16 Jun 2014 04:47:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764000.660.1402908444813@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3504:
----------------------------------

    Fix Version/s: 3.5.11.Final
                   3.7.2.Final


> Upgrade Picketlink IDM to 1.4.5.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3504
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.1.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.8.3.Final, 3.9.0.Final
>
>




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

From issues at jboss.org  Mon Jun 16 04:49:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Mon, 16 Jun 2014 04:49:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764000.677.1402908564980@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran commented on GTNPORTAL-3504:
---------------------------------------

I also committed to master. [~mposolda] Could you take care of it for 3.8.x branch ?

> Upgrade Picketlink IDM to 1.4.5.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3504
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.1.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.8.3.Final, 3.9.0.Final
>
>




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

From issues at jboss.org  Mon Jun 16 04:49:25 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Mon, 16 Jun 2014 04:49:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3507) Update test case from
 PLIDM-46 to gatein-portal code base
In-Reply-To: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543006.1402037371000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543006.1402037371000.680.1402908565375@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3507:
----------------------------------

    Fix Version/s:     (was: 3.9.0.Final)
                       (was: 3.7.2.Final)


> Update test case from PLIDM-46 to gatein-portal code base
> ---------------------------------------------------------
>
>                 Key: GTNPORTAL-3507
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3507
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.10.Final
>            Reporter: Tran Trung Thanh
>             Fix For: 3.5.11.Final
>
>
> PLIDM-46 contains a new unit case to verify that PLIDM transaction is synchronized with Hibernate transaction. This test should be included in gatein-portal code base  



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

From issues at jboss.org  Mon Jun 16 04:57:24 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 16 Jun 2014 04:57:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-40) NPE in WCM Content
	configuration portlet
In-Reply-To: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543936.1402909000000.696.1402909044813@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNWCM-40:
------------------------------

    Description: NPE thrown in WCM Content configuration after import phase.


> NPE in WCM Content configuration portlet
> ----------------------------------------
>
>                 Key: GTNWCM-40
>                 URL: https://issues.jboss.org/browse/GTNWCM-40
>             Project: GateIn WCM
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>
> NPE thrown in WCM Content configuration after import phase.



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

From issues at jboss.org  Mon Jun 16 04:57:24 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 16 Jun 2014 04:57:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-40) NPE in WCM Content
	configuration portlet
In-Reply-To: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543936.1402909000000.695.1402909044761@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce reassigned GTNWCM-40:
---------------------------------

    Assignee: Lucas Ponce


> NPE in WCM Content configuration portlet
> ----------------------------------------
>
>                 Key: GTNWCM-40
>                 URL: https://issues.jboss.org/browse/GTNWCM-40
>             Project: GateIn WCM
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>




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

From issues at jboss.org  Mon Jun 16 04:57:24 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 16 Jun 2014 04:57:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-40) NPE in WCM Content
	configuration portlet
In-Reply-To: <JIRA.12543936.1402909000773@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543936.1402909000773@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543936.1402909000773.694.1402909044698@jira02.app.mwc.hst.phx2.redhat.com>

Lucas Ponce created GTNWCM-40:
---------------------------------

             Summary: NPE in WCM Content configuration portlet
                 Key: GTNWCM-40
                 URL: https://issues.jboss.org/browse/GTNWCM-40
             Project: GateIn WCM
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Lucas Ponce






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

From issues at jboss.org  Mon Jun 16 07:57:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Jun 2014 07:57:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3485) Add an option to load
 AMD JavaScript from a CDN
In-Reply-To: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541211.1400577402000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541211.1400577402000.1317.1402919844471@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Add an option to load AMD JavaScript from a CDN
> -----------------------------------------------
>
>                 Key: GTNPORTAL-3485
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3485
>             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
>
>




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

From issues at jboss.org  Mon Jun 16 07:57:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 16 Jun 2014 07:57: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.1320.1402919844677@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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  Tue Jun 17 04:51:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 04:51:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3484) Commit changes for a
 page before send response
In-Reply-To: <JIRA.12541206.1400575908000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541206.1400575908000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541206.1400575908000.3985.1402995088939@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Commit changes for a page before send response
> ----------------------------------------------
>
>                 Key: GTNPORTAL-3484
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3484
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>
> In current design a call to RequestLifeCycle.end() is performed at the end of the request meanwhile a markup can be send it before with portlets ID not yet commited.
> This can cause some StaleModelException cases under heavy load or database congestion.



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

From issues at jboss.org  Tue Jun 17 04:51:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 04:51:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-2581) RichFaces is not
 defined after adding a RF portlet to a page
In-Reply-To: <JIRA.12474884.1348062188000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12474884.1348062188000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474884.1348062188000.3986.1402995088989@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> RichFaces is not defined after adding a RF portlet to a page
> ------------------------------------------------------------
>
>                 Key: GTNPORTAL-2581
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-2581
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>         Environment: GateIn 3.4.0.Final
>            Reporter: Peter Palaga
>         Attachments: jsf2-rf4-hello-world-portlet.war
>
>
> (1) Start a fresh GateIn 3.4.0.Final:
> cd tmp
> wget http://downloads.jboss.org/gatein/Releases/Portal/3.4.0.Final/GateIn-3.4.0.Final-jbossas7.zip 
> unzip GateIn-3.4.0.Final-jbossas7.zip
> cd GateIn-3.4.0.Final-jbossas7/bin
> ./standalone.sh
> (2) Install gatein-bom-3.4
> git clone https://github.com/ppalaga/gatein-bom.github
> cd gatein-bom
> mvn install -Dgpg.skip=true
> (3) Pack and deploy jsf2-rf4-hello-world-portlet:
> cd tmp
> git clone https://github.com/ppalaga/gatein-portal-quickstart.git
> cd gatein-portal-quickstart/jsf2-rf4-hello-world-portlet
> mvn package jboss-as:deploy
> (4)  In web browser:
> * login as root http://127.0.0.1:8080/portal/login?username=root&password=gtn&initialURI=/portal/classic/
> (5) In web browser:
> * Group > Administration > Application Registry > Import Applications
> * Site > Classic > Home
> * Site Editor > Edit Page
> * Drag jsf2-rf4-hello-world-portlet and drop it e.g. under the Home Page portlet
> * make the console with server log visible to you
> * Open developer tools (F12 in Chrome) and switch to Resources. Have a look at loaded scripts. Note that there are no PBR-related scripts there.
> (6) Hit Finish (Diskette Icon) in Page Editor dialog
> (7) UNEXPECTED: After hitting Finish, there comes a modal message in the browser window saying "RichFaces is not defined". 
> * Note that while this message is being displayed, there is no change in the scripts compared to before (5).
> * Note that nothing happened in the server log.
>  
> (8) Hit OK in the "RichFaces is not defined" alert.
> * Note that one or more PBR-related scripts were loaded. Some of them have error markers in them
> * Sometimes one or more org.exoplatform.portal.config.NoSuchDataExceptions appear in the server log
>  
> The problem seems to be related to the fact that the inline JavaScript needed to render the rich:select component is evaluated before the needed js resources were loaded. After reloading the whole page or accessing the page from another session jsf2-rf4-hello-world-portlet works as expected. 
> For further observations, define one more step:
> (9)
> * Site > Classic > Home
> * Site Editor > Edit Page
> * remove jsf2-rf4-hello-world-portlet from the page
> * Hit Finish (Diskette Icon) in Page Editor dialog
> When in the state after (8), one performs (9) and then again (5) and (6), "RichFaces is not defined" does not appear.
> "RichFaces is not defined" appears only when one signs out from the portal and signs in again between (9) and (5) of the previous scenario.



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

From issues at jboss.org  Tue Jun 17 08:32:24 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Tue, 17 Jun 2014 08:32:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3513) Layout of portlet is
 broken in preview mode using extensions
In-Reply-To: <JIRA.12544134.1403008296067@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544134.1403008296067@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544134.1403008296067.4686.1403008344477@jira02.app.mwc.hst.phx2.redhat.com>

Lucas Ponce created GTNPORTAL-3513:
--------------------------------------

             Summary: 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


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 Jun 17 08:36:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 08:36:24 -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.4738.1403008584554@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3513:
-----------------------------------------------

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


> 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
>
> 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 Jun 17 08:36:24 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Tue, 17 Jun 2014 08:36:24 -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.4739.1403008584652@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3513:
-----------------------------------

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


> 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
>
> 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 Jun 17 08:38:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 08:38:24 -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.4752.1403008704632@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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
>
> 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 Jun 17 09:09:26 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:09:26 -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.5036.1403010566408@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3503:
------------------------------------

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


> 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 Jun 17 09:15:29 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 09:15:29 -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.5049.1403010929990@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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 Jun 17 09:17:24 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:17:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3504) Upgrade Picketlink
	IDM to 1.4.5.Final
In-Reply-To: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542734.1401862764000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542734.1401862764000.5054.1403011044802@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3504:
------------------------------------

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


> Upgrade Picketlink IDM to 1.4.5.Final
> -------------------------------------
>
>                 Key: GTNPORTAL-3504
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3504
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.8.1.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.5.11.Final, 3.7.2.Final, 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 Jun 17 09:17:25 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:17:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3495) Membership Pagination
	don't work
In-Reply-To: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542051.1401206275000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542051.1401206275000.5057.1403011045110@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3495:
------------------------------------

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


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



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

From issues at jboss.org  Tue Jun 17 09:17:25 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:17:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3493) Membership just added,
	disappears
In-Reply-To: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541890.1401114872000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541890.1401114872000.5061.1403011045570@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3493:
------------------------------------

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


> Membership just added, disappears
> ---------------------------------
>
>                 Key: GTNPORTAL-3493
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3493
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Boubaker Khanfir
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>         Attachments: plidm-ldap-membership-disappear.zip
>
>
> I attach a new unit test for a bug that we met in GateIN 3.5 (PL IDM 1.4.4).
> This one shows how we can add a membership and just after that it disappears.
> In this file [idm-configuration.xml|https://github.com/gatein/gatein-portal/blob/3.5.x/web/portal/src/main/webapp/WEB-INF/conf/organization/idm-configuration.xml], the comment :
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For RW LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only and/or Read-only LDAP, it's recommended to not map anything here -->
> {quote}
> is not good and have to be like this:
> {quote}
>           <!-- if "associationMembershipType" option is used and this option is set to true
>                 then Membership with MembershipType configured to be stored as PicketLink IDM association
>                 will not be stored as PicketLink IDM Role in case that they are in groups from this parameter.
>                 For LDAP setup, it's recommended to map all groups mapped to LDAP (all those from parameter groupTypeMappings)
>                 However for DB only, it's recommended to not map anything here -->
> {quote}
> What changes in this comment ?
> The LDAP RW or ReadOnly have to get the same behavior using this parameter and we should map all LDAP groups in "ignoreMappedMembershipTypeGroupList".
> I think it's better to force/compute this parameter in OrganizationService instead of giving the ability to do it manually. The other solution is to modify OrganizationService Impl to deal with such a use case but I prefer the first choice.



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

From issues at jboss.org  Tue Jun 17 09:21:25 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:21:25 -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.5080.1403011285038@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3505:
------------------------------------

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


> WSRP Producers behind Load Balancers get wrong endpoint URL
> -----------------------------------------------------------
>
>                 Key: GTNPORTAL-3505
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.



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


From issues at jboss.org  Tue Jun 17 09:23:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 09:23: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.5092.1403011404357@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> WSRP Producers behind Load Balancers get wrong endpoint URL
> -----------------------------------------------------------
>
>                 Key: GTNPORTAL-3505
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3505
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Juraci Paix?o Kr?hling
>            Assignee: Juraci Paix?o Kr?hling
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733.



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


From issues at jboss.org  Tue Jun 17 09:25:24 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:25:24 -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.5094.1403011524317@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3494:
------------------------------------

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


> Names of imported applications in Application Registry are not localized 
> -------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3494
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3494
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: WebUI
>    Affects Versions: 3.8.1.Final
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>




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

From issues at jboss.org  Tue Jun 17 09:29:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 09:29:24 -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.5102.1403011764813@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Names of imported applications in Application Registry are not localized 
> -------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3494
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3494
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: WebUI
>    Affects Versions: 3.8.1.Final
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>




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

From issues at jboss.org  Tue Jun 17 09:29:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 09:29:25 -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.5105.1403011765091@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

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



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

From issues at jboss.org  Tue Jun 17 09:29:25 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:29:25 -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.5110.1403011765592@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3509:
------------------------------------

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


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



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

From issues at jboss.org  Tue Jun 17 09:31:25 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Tue, 17 Jun 2014 09:31:25 -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.5120.1403011885222@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3506:
------------------------------------

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


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



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

From issues at jboss.org  Tue Jun 17 10:58:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 17 Jun 2014 10:58:24 -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.5793.1403017104304@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3506:
-----------------------------------------------

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


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



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

From issues at jboss.org  Wed Jun 18 04:25:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Jun 2014 04:25:24 -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.7280.1403079924220@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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  Wed Jun 18 08:35:25 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 18 Jun 2014 08:35:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNCOMMON-21) Serialization of
 ParameterMap breaks with JBoss Marshalling
In-Reply-To: <JIRA.12530365.1390813730000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12530365.1390813730000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12530365.1390813730000.7813.1403094924997@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration commented on GTNCOMMON-21:
--------------------------------------------------

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

> Serialization of ParameterMap breaks with JBoss Marshalling
> -----------------------------------------------------------
>
>                 Key: GTNCOMMON-21
>                 URL: https://issues.jboss.org/browse/GTNCOMMON-21
>             Project: GateIn Common
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.1.1.Final
>         Environment: JPP 6.1.0
>            Reporter: Martin Weiler
>             Fix For: 2.2.0.Beta01, 2.1.2.Final
>
>
> Serialization of a ParameterMap instance with JBoss Marshalling (used by Infinispan) breaks with the following exception:
> {noformat}
> 15:20:33,853 ERROR [org.infinispan.marshall.VersionAwareMarshaller] (transport-thread-11) ISPN000065: Exception while marshalling object: java.io.NotActiveException: Fields were never written
> 	at org.jboss.marshalling.river.RiverObjectOutputStream.finish(RiverObjectOutputStream.java:175)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1009)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.jboss.as.clustering.SimpleMarshalledValue.getBytes(SimpleMarshalledValue.java:85)
> 	at org.jboss.as.clustering.SimpleMarshalledValue.writeExternal(SimpleMarshalledValue.java:175)
> 	at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:47)
> 	at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:36)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ForeignExternalizerAdapter.writeObject(ExternalizerTable.java:459)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallMap(MarshallUtil.java:59)
> 	at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:63)
> 	at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:47)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:250)
> 	at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:247)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:154)
> 	at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:150)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:103)
> 	at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:88)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50)
> 	at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeCommandParameters(ReplicableCommandExternalizer.java:87)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.marshallParameters(CacheRpcCommandExternalizer.java:128)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:112)
> 	at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:73)
> 	at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410)
> 	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145)
> 	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
> 	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
> 	at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:96)
> 	at org.infinispan.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:92)
> 	at org.infinispan.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:64)
> 	at org.infinispan.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:109)
> 	at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:45)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:279)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:300)
> 	at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
> 	at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
> 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
> 	at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190)
> 	at org.infinispan.statetransfer.OutboundTransferTask.sendEntries(OutboundTransferTask.java:257)
> 	at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:187)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> 	at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: an exception which occurred:
> 	in field parameters
> 	in field navigationalState
> 	in object java.util.HashMap at 7b2c68fe
> {noformat}
> The NotActiveException is a result of a broken writeObject implementation in org.gatein.common.util.ParameterMap, which does not call out.defaultWriteObject();



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

From issues at jboss.org  Wed Jun 18 11:17:25 2014
From: issues at jboss.org (Ahmed Zaoui (JIRA))
Date: Wed, 18 Jun 2014 11:17:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3489)
 [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
In-Reply-To: <JIRA.12541698.1400843865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541698.1400843865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541698.1400843865000.8544.1403104645894@jira02.app.mwc.hst.phx2.redhat.com>


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

Ahmed Zaoui updated GTNPORTAL-3489:
-----------------------------------

    Attachment: testDiffgatein-portal.patch


See in attachment test case to reproduce the issue where I try to link user to existing association:

{code} 

     org.picketlink.idm.api.User gtnUser = idmService_.getIdentitySession().getPersistenceManager().findUser(user.getUserName());
     org.picketlink.idm.api.Group gtnGroup = idmService_.getIdentitySession().getPersistenceManager().findGroupByKey(groupId);

       idmService_.getIdentitySession().getRelationshipManager().associateUser(gtnGroup, gtnUser);
       
       try {
         	 membershipHandler_.linkMembership(user, group1, mt, false);
  		} catch (Exception e) {
  			e.printStackTrace();
  		}
{code} 

In this test case the association was created using PicketLink IDM then call linkMembership from gatein api which will try to re-create this association (please refer to MembershipDAOImpl.java from idm implementation.
{code:java}
      if (isAssociationMapped() && getAssociationMapping().equals(mt.getName()))
      {
         getIdentitySession().getRelationshipManager().associateUserByKeys(groupId, user.getUserName());
      }
{code}

So running this test with oracle will give this stack trace:
{code}
 
[18:00:52-616][SEVERE] AbstractFlushingEventListener Could not synchronize database state with session org.hibernate.exception.ConstraintViolationException: could not insert: [org.picketlink.idm.impl.model.hibernate.HibernateIdentityObjectRelationship]
	at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:94)
	at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
	at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2285)
	at org.hibernate.persister.entity.AbstractEntityPersister.insert(AbstractEntityPersister.java:2678)
	at org.hibernate.action.EntityInsertAction.execute(EntityInsertAction.java:79)
	at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
	at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:167)
	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:1028)
	at sun.reflect.GeneratedMethodAccessor21.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:342)
	at com.sun.proxy.$Proxy29.flush(Unknown Source)
	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.createRelationship(HibernateIdentityStoreImpl.java:1203)
	at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.createRelationship(WrapperIdentityStoreRepository.java:245)
	at org.picketlink.idm.impl.api.session.managers.RelationshipManagerImpl.associateUserByKeys(RelationshipManagerImpl.java:375)
	at org.exoplatform.services.organization.idm.MembershipDAOImpl.linkMembership(MembershipDAOImpl.java:180)
	at org.exoplatform.services.organization.TestOrganizationService.testCommit(TestOrganizationService.java:183)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at junit.framework.TestCase.runTest(TestCase.java:164)
	at junit.framework.TestCase.runBare(TestCase.java:130)
	at org.exoplatform.component.test.AbstractGateInTest.runBare(AbstractGateInTest.java:87)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:120)
	at junit.framework.TestSuite.runTest(TestSuite.java:230)
	at junit.framework.TestSuite.run(TestSuite.java:225)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
	at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:165)
	at org.apache.maven.surefire.Surefire.run(Surefire.java:107)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:289)
	at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1005)
Caused by: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (GERAP.SYS_C0042804) violated

{code}

To configure test case with oracle you should update this configuration file TestOrganizationService-configuration.xml to use oracle dialect and add the oracle jdbc to the class path of the gatein project

In real  life this problem was reproduced with ldap connected to gatein and a customLoginModule added to the default configuration.

> [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
> ---------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3489
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3489
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Ahmed Zaoui
>            Priority: Minor
>         Attachments: testDiffgatein-portal.patch
>
>
> When synchronizing new user from ldap with an already created relationship we got this exception:
> {noformat}
> 2014-04-29 16:01:05,248 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ajp-arecasapps02/10.100.8.17:14011-2) ORA-00001: unique constraint (IDM.SYS_C0015551) violated
> 2014-04-29 16:01:05,257 WARN  Failed to call postSave for gerap User with listener : class org.exoplatform.services.organization.impl.NewUserEventListener: org.picketlink.idm.common.exception.IdentityException: Cannot create relationship: 
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.createRelationship(HibernateIdentityStoreImpl.java:1212) [picketlink-idm-hibernate.jar:1.4.4.Final]
> 	at org.picketlink.idm.impl.repository.FallbackIdentityStoreRepository.createRelationship(FallbackIdentityStoreRepository.java:1042) [picketlink-idm-core.jar:1.4.4.Final]
> 	at org.picketlink.idm.impl.api.session.managers.RelationshipManagerImpl.associateUserByKeys(RelationshipManagerImpl.java:375) [picketlink-idm-core.jar:1.4.4.Final]
> 	at org.exoplatform.services.organization.idm.MembershipDAOImpl.linkMembership(MembershipDAOImpl.java:132) [exo.portal.component.identity-3.5.9.Final_patched.jar:3.5.9.Final]
> 	at org.exoplatform.services.organization.impl.NewUserEventListener.createDefaultUserMemberships(NewUserEventListener.java:101) [exo.core.component.organization.api.jar:2.5.8-GA]
> 	at org.exoplatform.services.organization.impl.NewUserEventListener.postSave(NewUserEventListener.java:72) [exo.core.component.organization.api.jar:2.5.8-GA]
> {noformat}
> We should add test checking the existence of the association before creating new one



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

From issues at jboss.org  Wed Jun 18 11:21:26 2014
From: issues at jboss.org (Ahmed Zaoui (JIRA))
Date: Wed, 18 Jun 2014 11:21:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3489)
 [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
In-Reply-To: <JIRA.12541698.1400843865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541698.1400843865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541698.1400843865000.8604.1403104886687@jira02.app.mwc.hst.phx2.redhat.com>


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

Ahmed Zaoui commented on GTNPORTAL-3489:
----------------------------------------

 some  analysis because the problem seems to be more complicated than the issue itself:

By activating the show  sql log properties in hibernate test configuration file for oracle dialect:
{code:xml}
        <description>Default Hibernate Service</description>
        <property name="hibernate.hbm2ddl.auto" value="create-drop"/>
       <property name="hibernate.show_sql" value="true"/>
        <property name="hibernate.use_sql_comments" value="true"/> 
{code} 

You will notice that this insert sql statement which caused unique constraint violated  error:
{code:sql}
        into
            jbid_io_rel
            (FROM_IDENTITY, NAME, TO_IDENTITY, REL_TYPE, ID) 
        values
            (?, ?, ?, ?, ?)
{code}
{code:noformat}
18.06.2014 14:12:17 *ERROR* [main] SqlExceptionHelper: ORA-00001: unique constraint (GERAP.SYS_C0045636) violated
 (SqlExceptionHelper.java, line 144) 
Hibernate: 
    /* insert org.picketlink.idm.impl.model.hibernate.HibernateIdentityObjectRelationship
        */ insert 
        into
            jbid_io_rel
            (FROM_IDENTITY, NAME, TO_IDENTITY, REL_TYPE, ID) 
        values
            (?, ?, ?, ?, ?)
18.06.2014 14:12:17 *WARN * [main] SqlExceptionHelper: SQL Error: 1, SQLState: 23000 (SqlExceptionHelper.java, line 143) 
18.06.2014 14:12:17 *ERROR* [main] SqlExceptionHelper: ORA-00001: unique constraint (GERAP.SYS_C0045636) violated
 (SqlExceptionHelper.java, line 144) 
18.06.2014 14:12:17 *ERROR* [main] PicketLinkIDMOrganizationServiceImpl: ORA-00001: unique constraint (GERAP.SYS_C0045636) violated

{code}

Normal behaviour and the reason is clear (an already column exist with the same composite unique key).
to understand more the issue you should check the sql script to create  jbid_io_rel table :
generated script from oracle:
{code:sql}
Hibernate: 
    create table jbid_io_rel (
        ID number(19,0) not null,
        FROM_IDENTITY number(19,0) not null,
        NAME number(19,0),
        TO_IDENTITY number(19,0) not null,
        REL_TYPE number(19,0) not null,
        primary key (ID),
        unique (FROM_IDENTITY, NAME, TO_IDENTITY, REL_TYPE)
    )
{code}

Show create table from mysql:
{code:sql}
 jbid_io_rel | CREATE TABLE `jbid_io_rel` (
  `ID` bigint(20) NOT NULL AUTO_INCREMENT,
  `FROM_IDENTITY` bigint(20) NOT NULL,
  `NAME` bigint(20) DEFAULT NULL,
  `TO_IDENTITY` bigint(20) NOT NULL,
  `REL_TYPE` bigint(20) NOT NULL,
  PRIMARY KEY (`ID`),
  UNIQUE KEY `FROM_IDENTITY` (`FROM_IDENTITY`,`NAME`,`TO_IDENTITY`,`REL_TYPE`),
  KEY `FKE9BC4F6C2D9E6CE8` (`REL_TYPE`),
  KEY `FKE9BC4F6C4EF6CBA4` (`NAME`),
  KEY `FKE9BC4F6CE5991E18` (`TO_IDENTITY`),
  KEY `FKE9BC4F6C89DEF9C9` (`FROM_IDENTITY`),
  CONSTRAINT `FKE9BC4F6C89DEF9C9` FOREIGN KEY (`FROM_IDENTITY`) REFERENCES `jbid_io` (`ID`),
  CONSTRAINT `FKE9BC4F6C2D9E6CE8` FOREIGN KEY (`REL_TYPE`) REFERENCES `jbid_io_rel_type` (`ID`),
  CONSTRAINT `FKE9BC4F6C4EF6CBA4` FOREIGN KEY (`NAME`) REFERENCES `jbid_io_rel_name` (`ID`),
  CONSTRAINT `FKE9BC4F6CE5991E18` FOREIGN KEY (`TO_IDENTITY`) REFERENCES `jbid_io` (`ID`)
) ENGINE=InnoDB AUTO_INCREMENT=78 DEFAULT CHARSET=latin1 |

{code}

So our constraint is :
{code:sql}
 UNIQUE KEY `FROM_IDENTITY` (`FROM_IDENTITY`,`NAME`,`TO_IDENTITY`,`REL_TYPE`)
{code}
 In fact what is considerate here as bug with oracle is the expected behaviour to keep the consistent state of the database, we add only a test case to ovoid this situation at java service layer before rejected from DB
returning now to our test case that will try to insert the same association ( the same composite key  (`FROM_IDENTITY`,`NAME`,`TO_IDENTITY`,`REL_TYPE`))
This is the result at database layer after running the attached test case:
*WITH ORACLE*
{noformat}
+----+---------------+------+-------------+----------+
| ID | FROM_IDENTITY | NAME | TO_IDENTITY | REL_TYPE |
+----+---------------+------+-------------+----------+
| 12 |            11 | NULL |           9 |        1 |
| 21 |             9 | NULL |          14 |        1 |
| 22 |             9 |   13 |          14 |        1 |
+----+---------------+------+-------------+----------+
{noformat}
With mysql :
{noformat}
+----+---------------+------+-------------+----------+
| ID | FROM_IDENTITY | NAME | TO_IDENTITY | REL_TYPE |
+----+---------------+------+-------------+----------+
|  2 |             1 | NULL |           3 |        1 |
| 73 |             1 | NULL |          39 |        1 |
|  3 |             1 |    1 |           3 |        2 |
| 74 |             1 |    1 |          39 |        2 |
|  1 |             2 | NULL |           1 |        1 |
| 72 |             2 | NULL |          38 |        1 |
| 75 |            38 | NULL |          39 |        1 |
| 76 |            38 | NULL |          39 |        1 |
| 77 |            38 |    1 |          39 |        2 |
+----+---------------+------+-------------+----------+
{noformat}
 As you can see there is no duplicated composite key with oracle as the constraint was respected 
However the same constraint was rejected with mysql and a duplicated composite entry is inserted (38,null,39,1) :
{noformat}
| 75 |            38 | NULL |          39 |        1 |
| 76 |            38 | NULL |          39 |        1 |
{noformat}

*So one question begs to be answered: why this unique constraint is not respected with mysql and HSQL DB*
*The response is :MySQL ignore null values on unique constraints*

> [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
> ---------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3489
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3489
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Ahmed Zaoui
>            Priority: Minor
>         Attachments: testDiffgatein-portal.patch
>
>
> When synchronizing new user from ldap with an already created relationship we got this exception:
> {noformat}
> 2014-04-29 16:01:05,248 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ajp-arecasapps02/10.100.8.17:14011-2) ORA-00001: unique constraint (IDM.SYS_C0015551) violated
> 2014-04-29 16:01:05,257 WARN  Failed to call postSave for gerap User with listener : class org.exoplatform.services.organization.impl.NewUserEventListener: org.picketlink.idm.common.exception.IdentityException: Cannot create relationship: 
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.createRelationship(HibernateIdentityStoreImpl.java:1212) [picketlink-idm-hibernate.jar:1.4.4.Final]
> 	at org.picketlink.idm.impl.repository.FallbackIdentityStoreRepository.createRelationship(FallbackIdentityStoreRepository.java:1042) [picketlink-idm-core.jar:1.4.4.Final]
> 	at org.picketlink.idm.impl.api.session.managers.RelationshipManagerImpl.associateUserByKeys(RelationshipManagerImpl.java:375) [picketlink-idm-core.jar:1.4.4.Final]
> 	at org.exoplatform.services.organization.idm.MembershipDAOImpl.linkMembership(MembershipDAOImpl.java:132) [exo.portal.component.identity-3.5.9.Final_patched.jar:3.5.9.Final]
> 	at org.exoplatform.services.organization.impl.NewUserEventListener.createDefaultUserMemberships(NewUserEventListener.java:101) [exo.core.component.organization.api.jar:2.5.8-GA]
> 	at org.exoplatform.services.organization.impl.NewUserEventListener.postSave(NewUserEventListener.java:72) [exo.core.component.organization.api.jar:2.5.8-GA]
> {noformat}
> We should add test checking the existence of the association before creating new one



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

From issues at jboss.org  Thu Jun 19 13:48:25 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 19 Jun 2014 13:48: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.11267.1403200105392@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3513:
------------------------------------

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


> 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  Thu Jun 19 13:50:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 19 Jun 2014 13:50:24 -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.11271.1403200224621@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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  Thu Jun 19 13:54:26 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 19 Jun 2014 13:54:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3510) Possible memory leaks,
 consistency issues and concurrency issues in ScriptGraph
In-Reply-To: <JIRA.12543336.1402405130000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543336.1402405130000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543336.1402405130000.11281.1403200466184@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3510:
------------------------------------

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


Merged this version:
https://github.com/gatein/gatein-portal/commit/ab54bfc1489e73610845f9ce44ec0e035f7c3988

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



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

From issues at jboss.org  Thu Jun 19 13:54:26 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 19 Jun 2014 13:54:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for
 JavaScript and skin services
In-Reply-To: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542445.1401481836000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542445.1401481836000.11285.1403200466561@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga commented on GTNPORTAL-3502:
-----------------------------------------

Tests added https://github.com/gatein/gatein-portal/commit/d1c07e977c3a63d59fec686821d3c14664b0c5f0

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



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

From issues at jboss.org  Thu Jun 19 22:56:24 2014
From: issues at jboss.org (Tran Trung Thanh (JIRA))
Date: Thu, 19 Jun 2014 22:56:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3365) Exception swallow in
 UserDaoImpl.persistUserInfo()
In-Reply-To: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529293.1389667726000.11929.1403232984914@jira02.app.mwc.hst.phx2.redhat.com>


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

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

I have added new commit for gatein-3.5's PR to avoid redundant messages after changing password https://github.com/ttthanh/gatein-portal/commit/a0d1948b437f585e1f757d24406302a502474d8d. Please port it to higher version if necessary.

> Exception swallow in UserDaoImpl.persistUserInfo()
> --------------------------------------------------
>
>                 Key: GTNPORTAL-3365
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3365
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.6.3.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> Under "{{org.exoplatform.services.organization.idm}}, 
> focus on : 
> {code:title=UserDAOImp.java|borderStyle=solid}
> public void persistUserInfo(User user, IdentitySession session) throws Exception
>    {
>       orgService.flush();
>       AttributesManager am = session.getAttributesManager();
>       ArrayList attributes = new ArrayList();
>       /* ... */
>       if (user.getPassword() != null)
>       {
>          if (orgService.getConfiguration().isPasswordAsAttribute())
>          {
>             attributes.add(new SimpleAttribute(USER_PASSWORD, user.getPassword()));
>          }
>          else
>          {
>             try
>             {
>                am.updatePassword(session.getPersistenceManager().findUser(user.getUserName()), user.getPassword());
>             }
>             catch (IdentityException e)
>             {
>                log.info("Cannot update password: " + user.getUserName() + "; ", e);
>             }
>          }
>       }
>       Attribute[] attrs = new Attribute[attributes.size()];
>       attrs = (Attribute[])attributes.toArray(attrs);
>       try
>       {
>          am.updateAttributes(user.getUserName(), attrs);
>       }
>       catch (IdentityException e)
>       {
>          log.info("Cannot update attributes for user: " + user.getUserName() + "; ", e);
>       }
>    } 
> {code} 
>  
> The method {{saveUser(User, boolean) _throws Exception_}} 
> calls 
> {{persistUserInfo(User user, IdentitySession session) _throws Exception_}}. 
>  
> Whereas, deeper in the code, you can easily notice that exceptions are caught in this level and traced by a {{log.info}}: 
> * first time in the password level
> * second time when updating all of the attributes. 
> (!) Users want to be notified when an error occurs during user registration.
> As well as being aware of the type of the caught exception.



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

From issues at jboss.org  Fri Jun 20 00:43:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 00:43:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3489)
 [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
In-Reply-To: <JIRA.12541698.1400843865000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541698.1400843865000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541698.1400843865000.11987.1403239404601@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran resolved GTNPORTAL-3489.
-----------------------------------

         Assignee: Trong Tran
    Fix Version/s: 3.5.11.Final
                   3.7.2.Final
                   3.9.0.Final
       Resolution: Done


> [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
> ---------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3489
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3489
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.5.9.Final
>            Reporter: Ahmed Zaoui
>            Assignee: Trong Tran
>            Priority: Minor
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>         Attachments: testDiffgatein-portal.patch
>
>
> When synchronizing new user from ldap with an already created relationship we got this exception:
> {noformat}
> 2014-04-29 16:01:05,248 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (ajp-arecasapps02/10.100.8.17:14011-2) ORA-00001: unique constraint (IDM.SYS_C0015551) violated
> 2014-04-29 16:01:05,257 WARN  Failed to call postSave for gerap User with listener : class org.exoplatform.services.organization.impl.NewUserEventListener: org.picketlink.idm.common.exception.IdentityException: Cannot create relationship: 
> 	at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.createRelationship(HibernateIdentityStoreImpl.java:1212) [picketlink-idm-hibernate.jar:1.4.4.Final]
> 	at org.picketlink.idm.impl.repository.FallbackIdentityStoreRepository.createRelationship(FallbackIdentityStoreRepository.java:1042) [picketlink-idm-core.jar:1.4.4.Final]
> 	at org.picketlink.idm.impl.api.session.managers.RelationshipManagerImpl.associateUserByKeys(RelationshipManagerImpl.java:375) [picketlink-idm-core.jar:1.4.4.Final]
> 	at org.exoplatform.services.organization.idm.MembershipDAOImpl.linkMembership(MembershipDAOImpl.java:132) [exo.portal.component.identity-3.5.9.Final_patched.jar:3.5.9.Final]
> 	at org.exoplatform.services.organization.impl.NewUserEventListener.createDefaultUserMemberships(NewUserEventListener.java:101) [exo.core.component.organization.api.jar:2.5.8-GA]
> 	at org.exoplatform.services.organization.impl.NewUserEventListener.postSave(NewUserEventListener.java:72) [exo.core.component.organization.api.jar:2.5.8-GA]
> {noformat}
> We should add test checking the existence of the association before creating new one



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

From issues at jboss.org  Fri Jun 20 03:19:25 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 03:19:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3365) Exception swallow in
 UserDaoImpl.persistUserInfo()
In-Reply-To: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529293.1389667726000.12172.1403248765992@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran commented on GTNPORTAL-3365:
---------------------------------------

thank [~thanhtt], I just updated on master following your comment at https://github.com/gatein/gatein-portal/commit/a6d9a890fb52276f422f9e527bdc8f9073038d21

[~ppalaga] Could you take care of 3.8.x ?

> Exception swallow in UserDaoImpl.persistUserInfo()
> --------------------------------------------------
>
>                 Key: GTNPORTAL-3365
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3365
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.6.3.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> Under "{{org.exoplatform.services.organization.idm}}, 
> focus on : 
> {code:title=UserDAOImp.java|borderStyle=solid}
> public void persistUserInfo(User user, IdentitySession session) throws Exception
>    {
>       orgService.flush();
>       AttributesManager am = session.getAttributesManager();
>       ArrayList attributes = new ArrayList();
>       /* ... */
>       if (user.getPassword() != null)
>       {
>          if (orgService.getConfiguration().isPasswordAsAttribute())
>          {
>             attributes.add(new SimpleAttribute(USER_PASSWORD, user.getPassword()));
>          }
>          else
>          {
>             try
>             {
>                am.updatePassword(session.getPersistenceManager().findUser(user.getUserName()), user.getPassword());
>             }
>             catch (IdentityException e)
>             {
>                log.info("Cannot update password: " + user.getUserName() + "; ", e);
>             }
>          }
>       }
>       Attribute[] attrs = new Attribute[attributes.size()];
>       attrs = (Attribute[])attributes.toArray(attrs);
>       try
>       {
>          am.updateAttributes(user.getUserName(), attrs);
>       }
>       catch (IdentityException e)
>       {
>          log.info("Cannot update attributes for user: " + user.getUserName() + "; ", e);
>       }
>    } 
> {code} 
>  
> The method {{saveUser(User, boolean) _throws Exception_}} 
> calls 
> {{persistUserInfo(User user, IdentitySession session) _throws Exception_}}. 
>  
> Whereas, deeper in the code, you can easily notice that exceptions are caught in this level and traced by a {{log.info}}: 
> * first time in the password level
> * second time when updating all of the attributes. 
> (!) Users want to be notified when an error occurs during user registration.
> As well as being aware of the type of the caught exception.



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

From issues at jboss.org  Fri Jun 20 03:47:25 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 03:47:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3365) Exception swallow in
 UserDaoImpl.persistUserInfo()
In-Reply-To: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529293.1389667726000.12218.1403250445544@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran edited comment on GTNPORTAL-3365 at 6/20/14 3:46 AM:
----------------------------------------------------------------

thank [~thanhtt], I just updated on master following your comment at https://github.com/gatein/gatein-portal/commit/a6d9a890fb52276f422f9e527bdc8f9073038d21

[~ppalaga] Could you take care of the updating on 3.8.x ?


was (Author: trong.tran):
thank [~thanhtt], I just updated on master following your comment at https://github.com/gatein/gatein-portal/commit/a6d9a890fb52276f422f9e527bdc8f9073038d21

[~ppalaga] Could you take care of 3.8.x ?

> Exception swallow in UserDaoImpl.persistUserInfo()
> --------------------------------------------------
>
>                 Key: GTNPORTAL-3365
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3365
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.6.3.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> Under "{{org.exoplatform.services.organization.idm}}, 
> focus on : 
> {code:title=UserDAOImp.java|borderStyle=solid}
> public void persistUserInfo(User user, IdentitySession session) throws Exception
>    {
>       orgService.flush();
>       AttributesManager am = session.getAttributesManager();
>       ArrayList attributes = new ArrayList();
>       /* ... */
>       if (user.getPassword() != null)
>       {
>          if (orgService.getConfiguration().isPasswordAsAttribute())
>          {
>             attributes.add(new SimpleAttribute(USER_PASSWORD, user.getPassword()));
>          }
>          else
>          {
>             try
>             {
>                am.updatePassword(session.getPersistenceManager().findUser(user.getUserName()), user.getPassword());
>             }
>             catch (IdentityException e)
>             {
>                log.info("Cannot update password: " + user.getUserName() + "; ", e);
>             }
>          }
>       }
>       Attribute[] attrs = new Attribute[attributes.size()];
>       attrs = (Attribute[])attributes.toArray(attrs);
>       try
>       {
>          am.updateAttributes(user.getUserName(), attrs);
>       }
>       catch (IdentityException e)
>       {
>          log.info("Cannot update attributes for user: " + user.getUserName() + "; ", e);
>       }
>    } 
> {code} 
>  
> The method {{saveUser(User, boolean) _throws Exception_}} 
> calls 
> {{persistUserInfo(User user, IdentitySession session) _throws Exception_}}. 
>  
> Whereas, deeper in the code, you can easily notice that exceptions are caught in this level and traced by a {{log.info}}: 
> * first time in the password level
> * second time when updating all of the attributes. 
> (!) Users want to be notified when an error occurs during user registration.
> As well as being aware of the type of the caught exception.



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

From issues at jboss.org  Fri Jun 20 03:53:25 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 03:53:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3365) Exception swallow in
 UserDaoImpl.persistUserInfo()
In-Reply-To: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12529293.1389667726000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529293.1389667726000.12248.1403250805519@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3365:
----------------------------------

    Fix Version/s: 3.5.11.Final
                   3.7.2.Final


> Exception swallow in UserDaoImpl.persistUserInfo()
> --------------------------------------------------
>
>                 Key: GTNPORTAL-3365
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3365
>             Project: GateIn Portal
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 3.6.3.Final
>            Reporter: Vu Viet Phuong
>            Assignee: Vu Viet Phuong
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.8.2.Final, 3.9.0.Final
>
>   Original Estimate: 4 hours
>          Time Spent: 6 hours
>  Remaining Estimate: 0 minutes
>
> Under "{{org.exoplatform.services.organization.idm}}, 
> focus on : 
> {code:title=UserDAOImp.java|borderStyle=solid}
> public void persistUserInfo(User user, IdentitySession session) throws Exception
>    {
>       orgService.flush();
>       AttributesManager am = session.getAttributesManager();
>       ArrayList attributes = new ArrayList();
>       /* ... */
>       if (user.getPassword() != null)
>       {
>          if (orgService.getConfiguration().isPasswordAsAttribute())
>          {
>             attributes.add(new SimpleAttribute(USER_PASSWORD, user.getPassword()));
>          }
>          else
>          {
>             try
>             {
>                am.updatePassword(session.getPersistenceManager().findUser(user.getUserName()), user.getPassword());
>             }
>             catch (IdentityException e)
>             {
>                log.info("Cannot update password: " + user.getUserName() + "; ", e);
>             }
>          }
>       }
>       Attribute[] attrs = new Attribute[attributes.size()];
>       attrs = (Attribute[])attributes.toArray(attrs);
>       try
>       {
>          am.updateAttributes(user.getUserName(), attrs);
>       }
>       catch (IdentityException e)
>       {
>          log.info("Cannot update attributes for user: " + user.getUserName() + "; ", e);
>       }
>    } 
> {code} 
>  
> The method {{saveUser(User, boolean) _throws Exception_}} 
> calls 
> {{persistUserInfo(User user, IdentitySession session) _throws Exception_}}. 
>  
> Whereas, deeper in the code, you can easily notice that exceptions are caught in this level and traced by a {{log.info}}: 
> * first time in the password level
> * second time when updating all of the attributes. 
> (!) Users want to be notified when an error occurs during user registration.
> As well as being aware of the type of the caught exception.



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

From issues at jboss.org  Fri Jun 20 05:50:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 05:50:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3492) Providing an
 extensible searching for skins in SkinService
In-Reply-To: <JIRA.12541861.1401097759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541861.1401097759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541861.1401097759000.12424.1403257824247@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3492:
----------------------------------

    Fix Version/s: 3.5.11.Final


> Providing an extensible searching for skins in SkinService
> ----------------------------------------------------------
>
>                 Key: GTNPORTAL-3492
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3492
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final
>
>




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

From issues at jboss.org  Fri Jun 20 05:50:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 05:50:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3492) Providing an
 extensible searching for skins in SkinService
In-Reply-To: <JIRA.12541861.1401097759000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12541861.1401097759000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12541861.1401097759000.12426.1403257824403@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3492:
----------------------------------

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


> Providing an extensible searching for skins in SkinService
> ----------------------------------------------------------
>
>                 Key: GTNPORTAL-3492
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3492
>             Project: GateIn Portal
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>            Reporter: Trong Tran
>            Assignee: Trong Tran
>             Fix For: 3.5.11.Final, 3.7.2.Final, 3.9.0.Final
>
>




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

From issues at jboss.org  Fri Jun 20 05:52:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Fri, 20 Jun 2014 05:52:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3498) Errors on
	TestSocialNetworkService
In-Reply-To: <JIRA.12542132.1401276072000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12542132.1401276072000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542132.1401276072000.12428.1403257944203@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3498:
----------------------------------

    Fix Version/s: 3.7.2.Final


> Errors on TestSocialNetworkService
> ----------------------------------
>
>                 Key: GTNPORTAL-3498
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3498
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 3.7.2.Final, 3.8.2.Final, 3.9.0.Final
>
>         Attachments: org.gatein.security.oauth.test.TestSocialNetworkService.txt
>
>
> Due GTNPORTAL-3365 some tests gets some unexpected exceptions.



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

From issues at jboss.org  Fri Jun 20 14:44:25 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Fri, 20 Jun 2014 14:44:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3514)
 PicketLinkIDMOrganizationServiceImpl is not serializable
In-Reply-To: <JIRA.12544539.1403289799125@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544539.1403289799125@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544539.1403289799125.13441.1403289865297@jira02.app.mwc.hst.phx2.redhat.com>

Marek Posolda created GTNPORTAL-3514:
----------------------------------------

             Summary: PicketLinkIDMOrganizationServiceImpl is not serializable
                 Key: GTNPORTAL-3514
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3514
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
          Components: Identity integration
    Affects Versions: 3.8.2.Final
            Reporter: Marek Posolda
            Assignee: Marek Posolda
             Fix For: 3.8.3.Final, 3.9.0.Final


Steps to reproduce:
- Configure GateIn with 2 nodes cluster
- Login as root and display OrganizationManagementPortlet
- There is exception in log like:
{code}
Caused by: org.infinispan.marshall.NotSerializableException: Type TypeModel[name=org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl] is not serializable
{code}



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

From issues at jboss.org  Fri Jun 20 15:29:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Jun 2014 15:29:24 -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.13503.1403292564435@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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  Fri Jun 20 15:29:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Jun 2014 15:29:24 -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.13506.1403292564659@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3500:
-----------------------------------------------

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


> 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  Fri Jun 20 16:18:24 2014
From: issues at jboss.org (Marek Posolda (JIRA))
Date: Fri, 20 Jun 2014 16:18:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3514)
 PicketLinkIDMOrganizationServiceImpl is not serializable
In-Reply-To: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544539.1403289799000.13569.1403295504043@jira02.app.mwc.hst.phx2.redhat.com>


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

Marek Posolda updated GTNPORTAL-3514:
-------------------------------------

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


> PicketLinkIDMOrganizationServiceImpl is not serializable
> --------------------------------------------------------
>
>                 Key: GTNPORTAL-3514
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3514
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> Steps to reproduce:
> - Configure GateIn with 2 nodes cluster
> - Login as root and display OrganizationManagementPortlet
> - There is exception in log like:
> {code}
> Caused by: org.infinispan.marshall.NotSerializableException: Type TypeModel[name=org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl] is not serializable
> {code}



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

From issues at jboss.org  Fri Jun 20 16:20:28 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 20 Jun 2014 16:20:28 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3514)
 PicketLinkIDMOrganizationServiceImpl is not serializable
In-Reply-To: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544539.1403289799000.13571.1403295628206@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3514:
-----------------------------------------------

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


> PicketLinkIDMOrganizationServiceImpl is not serializable
> --------------------------------------------------------
>
>                 Key: GTNPORTAL-3514
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3514
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> Steps to reproduce:
> - Configure GateIn with 2 nodes cluster
> - Login as root and display OrganizationManagementPortlet
> - There is exception in log like:
> {code}
> Caused by: org.infinispan.marshall.NotSerializableException: Type TypeModel[name=org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl] is not serializable
> {code}



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

From issues at jboss.org  Sat Jun 21 06:33:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 21 Jun 2014 06:33: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.13696.1403346804213@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> Different Portlet preference for remote portlets added on the same page
> -----------------------------------------------------------------------
>
>                 Key: GTNWSRP-376
>                 URL: https://issues.jboss.org/browse/GTNWSRP-376
>             Project: GateIn WSRP
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 2.2.11.Final
>         Environment: Tested with :
> JBoss Portal Platform - 6.1.1 (GateIn Portal 3.6.5)  and 
> GateIn-3.8.0.Beta01
>            Reporter: Anurag Debnath
>            Assignee: Juraci Paix?o Kr?hling
>         Attachments: PortletPreferencesPortlet.war.zip
>
>
> When two instances of the same remote portlet is added to the same page, changes made to the preferences of one portlet is picked up by the other portlet as well.
> Ideally, portlets should get their own preference/s.



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


From issues at jboss.org  Sat Jun 21 06:45:26 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 21 Jun 2014 06:45:26 -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.13708.1403347526757@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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  Sat Jun 21 07:17:24 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Sat, 21 Jun 2014 07:17:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3514)
 PicketLinkIDMOrganizationServiceImpl is not serializable
In-Reply-To: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544539.1403289799000.13723.1403349444352@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga updated GTNPORTAL-3514:
------------------------------------

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


> PicketLinkIDMOrganizationServiceImpl is not serializable
> --------------------------------------------------------
>
>                 Key: GTNPORTAL-3514
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3514
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.8.3.Final, 3.9.0.Final
>
>
> Steps to reproduce:
> - Configure GateIn with 2 nodes cluster
> - Login as root and display OrganizationManagementPortlet
> - There is exception in log like:
> {code}
> Caused by: org.infinispan.marshall.NotSerializableException: Type TypeModel[name=org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl] is not serializable
> {code}



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

From issues at jboss.org  Sun Jun 22 21:58:23 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Sun, 22 Jun 2014 21:58:23 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3515) Should refresh data
 in Membership management form without relogin
In-Reply-To: <JIRA.12544565.1403488633817@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544565.1403488633817@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544565.1403488633817.14347.1403488703993@jira02.app.mwc.hst.phx2.redhat.com>

Tuyen Nguyen The created GTNPORTAL-3515:
-------------------------------------------

             Summary: 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


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  Sun Jun 22 21:58:24 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Sun, 22 Jun 2014 21:58: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.14348.1403488704057@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The reassigned GTNPORTAL-3515:
-------------------------------------------

    Assignee: Tuyen Nguyen The


> 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
>
> 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  Sun Jun 22 22:02:23 2014
From: issues at jboss.org (Tuyen Nguyen The (JIRA))
Date: Sun, 22 Jun 2014 22:02:23 -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.14360.1403488943983@jira02.app.mwc.hst.phx2.redhat.com>


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

Tuyen Nguyen The updated GTNPORTAL-3515:
----------------------------------------

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


> 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
>
> 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  Sun Jun 22 22:34:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Sun, 22 Jun 2014 22: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.14364.1403490864257@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:
----------------------------------

    Priority: Minor  (was: Major)


> 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
>
> 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 Jun 23 12:34:24 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Mon, 23 Jun 2014 12:34:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3516)
 NotSerializableException:
 org.exoplatform.services.organization.impl.UserImpl
In-Reply-To: <JIRA.12544632.1403541163794@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544632.1403541163794@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544632.1403541163794.16240.1403541264147@jira02.app.mwc.hst.phx2.redhat.com>

Peter Palaga created GTNPORTAL-3516:
---------------------------------------

             Summary: NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
                 Key: GTNPORTAL-3516
                 URL: https://issues.jboss.org/browse/GTNPORTAL-3516
             Project: GateIn Portal
          Issue Type: Bug
      Security Level: Public (Everyone can see)
            Reporter: Peter Palaga
            Assignee: Peter Palaga
             Fix For: 3.8.4.Final


Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1112159
Description of problem:
When retesting Bug GTNPORTAL-3514 with new bundle I found another issue.

Steps to Reproduce:
1. start node1
2. login as root
3. go to Organization Portlet
4. start node2

Actual results:
- node1: org.infinispan.marshall.NotSerializableException: org.exoplatform.services.organization.impl.UserImpl

- node2: org.infinispan.CacheException: Initial state transfer timed out for cache idm-portal-api on node2-56105




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

From issues at jboss.org  Tue Jun 24 03:24:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Jun 2014 03:24:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3516)
 NotSerializableException:
 org.exoplatform.services.organization.impl.UserImpl
In-Reply-To: <JIRA.12544632.1403541163000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544632.1403541163000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544632.1403541163000.17061.1403594664657@jira02.app.mwc.hst.phx2.redhat.com>


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

RH Bugzilla Integration updated GTNPORTAL-3516:
-----------------------------------------------

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


> NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
> -----------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3516
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3516
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.4.Final
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1112159
> Description of problem:
> When retesting Bug GTNPORTAL-3514 with new bundle I found another issue.
> Steps to Reproduce:
> 1. start node1
> 2. login as root
> 3. go to Organization Portlet
> 4. start node2
> Actual results:
> - node1: org.infinispan.marshall.NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
> - node2: org.infinispan.CacheException: Initial state transfer timed out for cache idm-portal-api on node2-56105



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

From issues at jboss.org  Tue Jun 24 06:29:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Jun 2014 06:29:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3475) NPE in
 LinkedList$ListItr.next when iterating over
 UIGroupMembershipSelect.getListMemberhip()
In-Reply-To: <JIRA.12540331.1399635695000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12540331.1399635695000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12540331.1399635695000.17361.1403605764180@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> NPE in LinkedList$ListItr.next when iterating over UIGroupMembershipSelect.getListMemberhip()
> ---------------------------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3475
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3475
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.2.Final, 3.9.0.Final
>
>         Attachments: GTNPORTAL-3475.log
>
>
> Looks like a concurrent modification of  the {{LinkedList}} refered to by {{UIGroupMembershipSelect.listMemberhip}}, because:
> i. It is not always reproducible, the NPE occurs roughly once per 10 attempts.
> ii. It happens on line {{next = next.next}} of the JRE's {{LinkedList.ListItr}} where it is hard to thing of anything else than concurrent modification as a cause.
> Steps to reproduce:
> (1) Start clean Portal instance for the first time
> (2) Go to Application Registry
> (3) Import Applications
> Not OK: There is an NPE logged (the whole log is attached):
> {code:none}
> Caused by: java.lang.NullPointerException
> 	at java.util.LinkedList$ListItr.next(LinkedList.java:891) [rt.jar:1.7.0_55]
> 	at UIGroupMembershipSelector.run(UIGroupMembershipSelector.gtmpl:20)	at org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:99) [exo.portal.component.scripting-3.8.0.Beta02-SNAPSHOT.jar:3.8.0.Beta02-SNAPSHOT]
> 	at org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:115) [exo.portal.component.scripting-3.8.0.Beta02-SNAPSHOT.jar:3.8.0.Beta02-SNAPSHOT]
> {code}
> Expected: No NPE



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

From issues at jboss.org  Tue Jun 24 12:03:24 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 24 Jun 2014 12:03:24 -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.18314.1403625804817@jira02.app.mwc.hst.phx2.redhat.com>


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

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

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

> 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  Wed Jun 25 04:35:26 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Wed, 25 Jun 2014 04:35:26 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3514)
 PicketLinkIDMOrganizationServiceImpl is not serializable
In-Reply-To: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544539.1403289799000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544539.1403289799000.19530.1403685326478@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran updated GTNPORTAL-3514:
----------------------------------

    Fix Version/s: 3.7.2.Final


> PicketLinkIDMOrganizationServiceImpl is not serializable
> --------------------------------------------------------
>
>                 Key: GTNPORTAL-3514
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3514
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>          Components: Identity integration
>    Affects Versions: 3.8.2.Final
>            Reporter: Marek Posolda
>            Assignee: Marek Posolda
>             Fix For: 3.7.2.Final, 3.8.3.Final, 3.9.0.Final
>
>
> Steps to reproduce:
> - Configure GateIn with 2 nodes cluster
> - Login as root and display OrganizationManagementPortlet
> - There is exception in log like:
> {code}
> Caused by: org.infinispan.marshall.NotSerializableException: Type TypeModel[name=org.exoplatform.services.organization.idm.PicketLinkIDMOrganizationServiceImpl] is not serializable
> {code}



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

From issues at jboss.org  Wed Jun 25 06:14:24 2014
From: issues at jboss.org (Trong Tran (JIRA))
Date: Wed, 25 Jun 2014 06:14:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3516)
 NotSerializableException:
 org.exoplatform.services.organization.impl.UserImpl
In-Reply-To: <JIRA.12544632.1403541163000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544632.1403541163000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544632.1403541163000.19838.1403691264276@jira02.app.mwc.hst.phx2.redhat.com>


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

Trong Tran commented on GTNPORTAL-3516:
---------------------------------------

This has been fixed at https://jira.exoplatform.org/browse/COR-325.

FYI, eXo JCR 1.16.1-GA will be released on July the 3th

> NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
> -----------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3516
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3516
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.4.Final
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1112159
> Description of problem:
> When retesting Bug GTNPORTAL-3514 with new bundle I found another issue.
> Steps to Reproduce:
> 1. start node1
> 2. login as root
> 3. go to Organization Portlet
> 4. start node2
> Actual results:
> - node1: org.infinispan.marshall.NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
> - node2: org.infinispan.CacheException: Initial state transfer timed out for cache idm-portal-api on node2-56105



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

From issues at jboss.org  Thu Jun 26 02:42:24 2014
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 26 Jun 2014 02:42:24 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3516)
 NotSerializableException:
 org.exoplatform.services.organization.impl.UserImpl
In-Reply-To: <JIRA.12544632.1403541163000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12544632.1403541163000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544632.1403541163000.22279.1403764944484@jira02.app.mwc.hst.phx2.redhat.com>


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

Peter Palaga commented on GTNPORTAL-3516:
-----------------------------------------

Thanks for the update, Trong. 

Just for the record: COR-325 will solve this issue for GateIn master branch (a.k.a. GateIn 3.9.x).

> NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
> -----------------------------------------------------------------------------
>
>                 Key: GTNPORTAL-3516
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3516
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>             Fix For: 3.8.4.Final
>
>
> Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1112159
> Description of problem:
> When retesting Bug GTNPORTAL-3514 with new bundle I found another issue.
> Steps to Reproduce:
> 1. start node1
> 2. login as root
> 3. go to Organization Portlet
> 4. start node2
> Actual results:
> - node1: org.infinispan.marshall.NotSerializableException: org.exoplatform.services.organization.impl.UserImpl
> - node2: org.infinispan.CacheException: Initial state transfer timed out for cache idm-portal-api on node2-56105



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

From issues at jboss.org  Sat Jun 28 11:28:35 2014
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Sat, 28 Jun 2014 11:28:35 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3435) Import .zip REST API
 broken with EAP 6.3.0.Alpha1
In-Reply-To: <JIRA.12536480.1396020937000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12536480.1396020937000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12536480.1396020937000.26393.1403969315609@jira02.app.mwc.hst.phx2.redhat.com>


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

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

mark yarborough <myarboro at redhat.com> changed the Status of [bug 1083054|https://bugzilla.redhat.com/show_bug.cgi?id=1083054] from VERIFIED to CLOSED

> Import .zip REST API broken with EAP 6.3.0.Alpha1
> -------------------------------------------------
>
>                 Key: GTNPORTAL-3435
>                 URL: https://issues.jboss.org/browse/GTNPORTAL-3435
>             Project: GateIn Portal
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>         Attachments: jbossweb-7.4.1.Final.jar, portal_classic_2014-03-28_16-59-29.zip
>
>
> A curl operation over template/user API:
> curl -i -H "Content-Type: application/zip" -u root:gtn -X PUT -T examples/user.zip "http://localhost:8080/rest/private/managed-components/template/user"
> hangs with:
> 16:35:16,466 INFO  [org.exoplatform.portal.mop.management.operations.TemplateImportResource] (http-/127.0.0.1:8080-4) Import successful !
> 16:35:16,475 ERROR [org.apache.catalina.connector] (http-/127.0.0.1:8080-4) JBWEB001018: An exception or error occurred in the container during the request processing: java.nio.BufferOverflowException
>         at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:357) [rt.jar:1.7.0_25]
>         at org.apache.coyote.http11.InternalNioOutputBuffer.commit(InternalNioOutputBuffer.java:666) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProcessor.commit(Http11NioProcessor.java:480) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProcessor.action(Http11NioProcessor.java:798) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.Response.action(Response.java:190) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.Response.sendHeaders(Response.java:390) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:352) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:318) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.Response.finishResponse(Response.java:487) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:371) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProcessor.process(Http11NioProcessor.java:353) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.process(Http11NioProtocol.java:911) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:920) [jbossweb-7.4.0.Beta4.jar:7.4.0.Beta4]
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
>         at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]



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

From issues at jboss.org  Mon Jun 30 04:53:25 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 30 Jun 2014 04:53:25 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher
 doesn't support IPv6 addresses
In-Reply-To: <JIRA.12543342.1402408197000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543342.1402408197000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543342.1402408197000.28521.1404118405666@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNPORTAL-3511:
-----------------------------------

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


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



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

From issues at jboss.org  Mon Jun 30 04:55:30 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 30 Jun 2014 04:55:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-40) NPE in WCM Content
	configuration portlet
In-Reply-To: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543936.1402909000000.28567.1404118530363@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce commented on GTNWCM-40:
-----------------------------------

Fixed on commit:
https://github.com/gatein/gatein-wcm/commit/740f2cfafb63d9dd5da540daf634d60acbba8316

> NPE in WCM Content configuration portlet
> ----------------------------------------
>
>                 Key: GTNWCM-40
>                 URL: https://issues.jboss.org/browse/GTNWCM-40
>             Project: GateIn WCM
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 2.x
>
>
> NPE thrown in WCM Content configuration after import phase.



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

From issues at jboss.org  Mon Jun 30 04:55:30 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 30 Jun 2014 04:55:30 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-40) NPE in WCM Content
	configuration portlet
In-Reply-To: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543936.1402909000000.28570.1404118530900@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce updated GTNWCM-40:
------------------------------

    Fix Version/s: 2.x


> NPE in WCM Content configuration portlet
> ----------------------------------------
>
>                 Key: GTNWCM-40
>                 URL: https://issues.jboss.org/browse/GTNWCM-40
>             Project: GateIn WCM
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 2.x
>
>
> NPE thrown in WCM Content configuration after import phase.



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

From issues at jboss.org  Mon Jun 30 04:55:31 2014
From: issues at jboss.org (Lucas Ponce (JIRA))
Date: Mon, 30 Jun 2014 04:55:31 -0400 (EDT)
Subject: [gatein-issues] [JBoss JIRA] (GTNWCM-40) NPE in WCM Content
	configuration portlet
In-Reply-To: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
References: <JIRA.12543936.1402909000000@jira02.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543936.1402909000000.28571.1404118531011@jira02.app.mwc.hst.phx2.redhat.com>


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

Lucas Ponce resolved GTNWCM-40.
-------------------------------

    Resolution: Done


> NPE in WCM Content configuration portlet
> ----------------------------------------
>
>                 Key: GTNWCM-40
>                 URL: https://issues.jboss.org/browse/GTNWCM-40
>             Project: GateIn WCM
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>            Reporter: Lucas Ponce
>            Assignee: Lucas Ponce
>             Fix For: 2.x
>
>
> NPE thrown in WCM Content configuration after import phase.



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