July 2011 - gatein-issues - Jboss List Archives

[JBoss JIRA] Created: (GTNWSRP-2) Unify management of configuration files between producer and consumer

by Chris Laprun (JIRA)

Unify management of configuration files between producer and consumer --------------------------------------------------------------------- Key: GTNWSRP-2 URL: https://jira.jboss.org/jira/browse/GTNWSRP-2 Project: GateIn WSRP Issue Type: Feature Request Affects Versions: 1.0.0-Beta01 Reporter: Chris Laprun Assignee: Chris Laprun Consumer files are in the consumer jar, producer files are found in WEB-INF of the war file. The producer file should maybe be in the producer jar as well... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
5
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1937) WSRP Producer Setup: Add "registrationRequired" to wsrp-producer-config.xml

by Christoph Hennes (JIRA)

WSRP Producer Setup: Add "registrationRequired" to wsrp-producer-config.xml --------------------------------------------------------------------------- Key: GTNPORTAL-1937 URL: https://issues.jboss.org/browse/GTNPORTAL-1937 Project: GateIn Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: WSRP integration Affects Versions: 3.1.0-GA Environment: EPP 5.1 Reporter: Christoph Hennes Assignee: Chris Laprun The initial WSRP producer file "wsrp-producer-config.xml" does not allow to configure the property "RegistrationRequired". This would be useful for avoiding manual installation steps after fresh portal setups. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
6
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1610) Cache portal config for the scope of the request

by Marek Posolda (JIRA)

Cache portal config for the scope of the request ------------------------------------------------ Key: GTNPORTAL-1610 URL: https://jira.jboss.org/browse/GTNPORTAL-1610 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Performance Affects Versions: 3.1.0-GA Environment: EPP 5.1.0 ER3 Reporter: Marek Posolda Assignee: Julien Viet I found another thing for logged user case performance, which can be improved. Issue is that method UserPortalConfigService.getUserPortalConfig() is called two times during HTTP request of logged user. And this method is expensive, because it performs other calls to IDM and DataStorage. So it should be possible to call it only once per HTTP request. Now it's called from: 1. LocalizationLifecycle.onStartRequest() 2. PortalStateManager.restoreUIRootComponent() . After this call is obtained UserPortalConfig saved as attribute into PortalRequestContext. It should be possible to save it into PortalRequestContext after LocalizationLifecycle.onStartRequest(), so that PortalStateManager.restoreUIRootComponent() can read it from PortalRequestContext. Or create another Lifecycle class for this purpose (Something similar to UserProfileLifecycle, which is doing similar thing for obtain UserProfile) ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1912) User Management - Delete user is invalid in special case

by Nguyen Thanh Cong (JIRA)

User Management - Delete user is invalid in special case -------------------------------------------------------- Key: GTNPORTAL-1912 URL: https://issues.jboss.org/browse/GTNPORTAL-1912 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Nguyen Thanh Cong r6550 - Go to User Managemnet - Search a user such as demo - Delete demo >> successfully. However, demo is still displayed. - Enter the other keyword to search >> error Exception: as to attempt to terminate the thread which caused the illegal access, and has no functional impact. java.lang.IllegalStateException at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1402) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1361) at sun.misc.Unsafe.defineClass(Native Method) at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45) at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381) at java.security.AccessController.doPrivileged(Native Method) at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377) at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:95) at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:313) at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1327) at java.io.ObjectStreamClass.access$1500(ObjectStreamClass.java:52) at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:437) at java.security.AccessController.doPrivileged(Native Method) at java.io.ObjectStreamClass.<init>(ObjectStreamClass.java:413) at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:310) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1106) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.exoplatform.commons.serialization.serial.DataContainer.writeExternal(DataContainer.java:68) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.exoplatform.commons.serialization.serial.DataContainer.writeExternal(DataContainer.java:68) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.exoplatform.commons.serialization.serial.DataContainer.writeExternal(DataContainer.java:68) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at java.util.ArrayList.writeObject(ArrayList.java:570) 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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.exoplatform.commons.serialization.serial.DataContainer.writeExternal(DataContainer.java:68) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at java.util.ArrayList.writeObject(ArrayList.java:570) 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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.exoplatform.commons.serialization.serial.DataContainer.writeExternal(DataContainer.java:68) at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1421) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1390) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.exoplatform.commons.serialization.SerializationContext.write(SerializationContext.java:105) at org.exoplatform.portal.application.replication.ApplicationState.writeObject(ApplicationState.java:95) 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 java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:945) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1461) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) at org.apache.catalina.session.StandardSession.writeObject(StandardSession.java:1546) at org.apache.catalina.session.StandardSession.writeObjectData(StandardSession.java:989) at org.apache.catalina.session.StandardManager.doUnload(StandardManager.java:517) at org.apache.catalina.session.StandardManager.unload(StandardManager.java:463) at org.apache.catalina.session.StandardManager.stop(StandardManager.java:667) at org.apache.catalina.core.StandardContext.stop(StandardContext.java:4611) at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java:924) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1319) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1290) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:323) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1086) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1098) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:448) at org.apache.catalina.core.StandardService.stop(StandardService.java:587) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:744) at org.apache.catalina.startup.Catalina.stop(Catalina.java:648) at org.apache.catalina.startup.Catalina$CatalinaShutdownHook.run(Catalina.java:692) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

5
11
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1886) Disabling option "associationMembershipType" in idm-configuration.xml when only DB (Hibernate) is used as identity store

by Marek Posolda (JIRA)

Disabling option "associationMembershipType" in idm-configuration.xml when only DB (Hibernate) is used as identity store ------------------------------------------------------------------------------------------------------------------------ Key: GTNPORTAL-1886 URL: https://issues.jboss.org/browse/GTNPORTAL-1886 Project: GateIn Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Identity integration Affects Versions: 3.1.0-GA Environment: EPP 5.1.0.GA Reporter: Marek Posolda Assignee: Boleslaw Dawidowicz Priority: Minor Fix For: 3.2.0-GA Right now, this option is enabled in idm-configuration.xml with value "member" . It means that when we are creating new membership with type "member", we need to call two picketlink API operations: 1) getIdentitySession().getRoleManager().createRole(mt.getName(), user.getUserName(), groupId) 2) getIdentitySession().getRelationshipManager().associateUserByKeys(groupId, user.getUserName()) I think that second call to relationshipManager is redundant and it does not make much sense. We don't need unnamed relationship when we already have named relationship with type "member" created by RoleManager. Right now, with option enabled, there are more necessary calls to Picketlink API and also more records in DB. Especially we have 2 records in DB in table "jbid_io_rel" for each membership of type "member" . One with NAME=NULL and one with NAME=2 (member) For example: mysql> select jbid_io_rel.* from jbid_io_rel inner join jbid_io on jbid_io.ID=jbid_io_rel.TO_IDENTITY where jbid_io.name like "john"; +----+---------------+------+-------------+----------+ | ID | FROM_IDENTITY | NAME | TO_IDENTITY | REL_TYPE | +----+---------------+------+-------------+----------+ | 22 | 3 | NULL | 19 | 1 | | 23 | 3 | 2 | 19 | 2 | | 24 | 4 | NULL | 19 | 1 | | 25 | 4 | 2 | 19 | 2 | | 26 | 8 | 1 | 19 | 2 | +----+---------------+------+-------------+----------+ 5 rows in set (0,00 sec) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1870) Login time of user "root" depends on number of users in DB

by Marek Posolda (JIRA)

Login time of user "root" depends on number of users in DB ---------------------------------------------------------- Key: GTNPORTAL-1870 URL: https://issues.jboss.org/browse/GTNPORTAL-1870 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Identity integration, Performance Affects Versions: 3.1.0-GA Environment: EPP 5.1.0.GA Reporter: Marek Posolda Assignee: Boleslaw Dawidowicz Fix For: 3.2.0-GA When we have 100000 users in DB, then login of user root took me 3 minutes on my laptop. With million users in DB is login of user root impossible . The cause is that method GroupDAOImpl.getAllGroups() is called for user "root" and CPU time of this method depends on number of users in database. This method has 2 possible bottlenecks: 1) Method GroupDAOImpl.getAllGroups() is internally running RelationshipManagerImpl.findAssociatedGroups for root group, which in next turn means recursive call of method RelationshipManagerImpl.findAssociatedGroups for each group in DB. This method is sending SQL, which is looking for all children under specified group. Problem is that these children can be both users or other groups and users are then filtered and removed from final result by algorithm at the end of method RelationshipManagerImpl.findAssociatedGroups(). When having 1000000 users and method RelationshipManagerImpl.findAssociatedGroups() is called for IDM group equivalent to "/platform/users", then we have 1000000 objects in result from Hibernate call. And this is the cause of bottleneck. This SQL is called (4 is ID of group "users" in table "jbid_io") : select distinct hibernatei1_.ID as ID4_, hibernatei1_.IDENTITY_TYPE as IDENTITY2_4_, hibernatei1_.NAME as NAME4_, hibernatei1_.REALM as REALM4_ from jbid_io_rel hibernatei0_ inner join jbid_io hibernatei1_ on hibernatei0_.TO_IDENTITY=hibernatei1_.ID, jbid_io_rel_type hibernatei3_ where hibernatei0_.REL_TYPE=hibernatei3_.ID and (hibernatei1_.NAME like '%') and hibernatei3_.NAME='JBOSS_IDENTITY_MEMBERSHIP' and hibernatei0_.FROM_IDENTITY=4; Running of this SQL is expensive and another thing, which I am seeing from profiling, is that big amount of CPU time is also spend by caching of this result in Hibernate Query Cache (which is very bad for memory as well because it needs to cache 1000000 HibernateIdentityObject instances with all users). 2) Second thing in GroupDAOImpl.getAllGroups() is calling of method convertGroup(), which needs to call DB requests to obtain attributes for concrete group. Hibernate is using these selects (for group with ID 1) for obtain attributes: select attributes0_.IDENTITY_OBJECT_ID as IDENTITY2_4_1_, attributes0_.ATTRIBUTE_ID as ATTRIBUTE1_1_, attributes0_.ATTRIBUTE_ID as ATTRIBUTE1_9_0_, attributes0_.IDENTITY_OBJECT_ID as IDENTITY2_9_0_, attributes0_.NAME as NAME9_0_, attributes0_.ATTRIBUTE_TYPE as ATTRIBUTE4_9_0_, attributes0_.BIN_VALUE_ID as BIN5_9_0_ from jbid_io_attr attributes0_ where attributes0_.IDENTITY_OBJECT_ID in (select hibernatei1_.ID from jbid_io_rel hibernatei0_ inner join jbid_io hibernatei1_ on hibernatei0_.TO_IDENTITY=hibernatei1_.ID, jbid_io_rel_type hibernatei3_ where hibernatei0_.REL_TYPE=hibernatei3_.ID and (hibernatei1_.NAME like '%') and hibernatei3_.NAME='JBOSS_IDENTITY_MEMBERSHIP' and hibernatei0_.FROM_IDENTITY=1); select textvalues0_.TEXT_ATTR_VALUE_ID as TEXT1_9_0_, textvalues0_.ATTR_VALUE as ATTR2_0_ from jbid_io_attr_text_values textvalues0_ where textvalues0_.TEXT_ATTR_VALUE_ID in (select attributes0_.ATTRIBUTE_ID from jbid_io_attr attributes0_ where attributes0_.IDENTITY_OBJECT_ID in (select hibernatei1_.ID from jbid_io_rel hibernatei0_ inner join jbid_io hibernatei1_ on hibernatei0_.TO_IDENTITY=hibernatei1_.ID, jbid_io_rel_type hibernatei3_ where hibernatei0_.REL_TYPE=hibernatei3_.ID and (hibernatei1_.NAME like '%') and hibernatei3_.NAME='JBOSS_IDENTITY_MEMBERSHIP' and hibernatei0_.FROM_IDENTITY=1)); When profiling, I am seeing that these selects are slow because attributes of groups are in same DB table as attributes of user ( When we have million users and each user has 7 attributes, then we have around 7000000 items in tables "jbid_io_attr" and in table "jbid_io_attr_text_values" ) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

3
3
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1692) Decouple gadget import process and gadget import metadata extraction

by Julien Viet (JIRA)

Decouple gadget import process and gadget import metadata extraction -------------------------------------------------------------------- Key: GTNPORTAL-1692 URL: https://jira.jboss.org/browse/GTNPORTAL-1692 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Reporter: Julien Viet Assignee: Julien Viet Gadget import details should be managed in the GadgetRegistryService. Gadget metadata extraction should be managed by the GadgetDeployer and the gadget importer. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (GTNWCI-26) Remove the .pom.xml.swp from test/servers

by Minh Hoang TO (JIRA)

Remove the .pom.xml.swp from test/servers ----------------------------------------- Key: GTNWCI-26 URL: https://issues.jboss.org/browse/GTNWCI-26 Project: GateIn Web Container Integration Issue Type: Task Reporter: Minh Hoang TO The swap file .pom.xml.swp was accidentally added into test/servers http://source.jboss.org/browse/GateIn/components/wci/trunk/test/servers -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
1
0 / 0

[JBoss JIRA] Created: (GTNPORTAL-1177) The day of the month in the calendar pop-up is not translated to French

by Trong Tran (JIRA)

The day of the month in the calendar pop-up is not translated to French ----------------------------------------------------------------------- Key: GTNPORTAL-1177 URL: https://jira.jboss.org/jira/browse/GTNPORTAL-1177 Project: GateIn Portal Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 3.0.0-GA Reporter: Trong Tran Assignee: Khoi Nguyen The day of the month in the calendar pop-up is not translated to French see attached screenshot In addition, this starts by Sunday. The days of the week must be in french and starts from Monday until Sunday. (see the attach file) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
2
0 / 0

[JBoss JIRA] Created: (GTNMAVEN-26) Upgrade JUEL to version 2.2.3 in gatein-dep

by Chris Laprun (JIRA)

Upgrade JUEL to version 2.2.3 in gatein-dep ------------------------------------------- Key: GTNMAVEN-26 URL: https://issues.jboss.org/browse/GTNMAVEN-26 Project: GateIn Maven Issue Type: Task Components: dep Affects Versions: dep-1.1.0-Beta03 Reporter: Chris Laprun Fix For: dep-1.1.0-Beta04 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 9 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues July 2011