[JBoss JIRA] (GTNPORTAL-3502) Commnon deployer for JavaScript and skin services
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3502?page=com.atlassian.jira.pl... ]
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)
9 years, 11 months
[JBoss JIRA] (GTNPORTAL-3493) Membership just added, disappears
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3493?page=com.atlassian.jira.pl... ]
Marek Posolda commented on GTNPORTAL-3493:
------------------------------------------
See documentation https://docs.jboss.org/author/display/GTNPORTAL38/LDAP+integration#LDAPin... 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/...], 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)
9 years, 11 months
[JBoss JIRA] (GTNPORTAL-3493) Membership just added, disappears
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3493?page=com.atlassian.jira.pl... ]
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/...], 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)
9 years, 11 months
[JBoss JIRA] (GTNCOMMON-21) Serialization of ParameterMap breaks with JBoss Marshalling
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNCOMMON-21?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration commented on GTNCOMMON-21:
--------------------------------------------------
Boleslaw Dawidowicz <bdawidow(a)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@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)
9 years, 11 months