[JBoss JIRA] (GTNPORTAL-3284) Errors in saving long accessToken for some socialNetworks
by Marek Posolda (JIRA)
Marek Posolda created GTNPORTAL-3284:
----------------------------------------
Summary: Errors in saving long accessToken for some socialNetworks
Key: GTNPORTAL-3284
URL: https://issues.jboss.org/browse/GTNPORTAL-3284
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.6.3.Final
Reporter: Marek Posolda
Assignee: Marek Posolda
Fix For: 3.7.0.Final
In some cases, it could happen that during binding of user to some social network (Facebook/Google/Twitter), the binding is not successful because of the fact that access token or refresh token is too long and DB throws error because of size limit of particular column (H2 has default limit of 255 characters per column)
The exception stacktrace could look like this:
{code}
12:06:50,595 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) SQL Error: 22001, SQLState: 22001
12:06:50,595 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) Value too long for column "ATTR_VALUE VARCHAR(255)": "STRINGDECODE('VvjdI6prHvZXN6CG95jWIpkPLS0i6WMtitYVNeE8TRIfI3y+sCOxxJRqKIP9iCojWCajhup0QTro\nUe0YrgTbhKQbH7fMLEYOWKgtTNDt2omE5A0g... (259)"; SQL statement:
insert into jbid_io_attr_text_values (TEXT_ATTR_VALUE_ID, ATTR_VALUE) values (?, ?) [22001-168]
12:06:50,597 INFO [org.exoplatform.services.organization.idm.UserProfileDAOImpl] (http-/127.0.0.1:8080-3) Identity operation error: : org.hibernate.exception.DataException: could not execute statement
at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:134)
at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:136)
at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:58)
at org.hibernate.persister.collection.AbstractCollectionPersister.insertRows(AbstractCollectionPersister.java:1474)
at org.hibernate.action.internal.CollectionUpdateAction.execute(CollectionUpdateAction.java:86)
at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:278)
at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:328)
at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:62)
at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1205)
at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1655)
at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:374)
at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getAttributes(HibernateIdentityStoreImpl.java:2108) [picketlink-idm-hibernate-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.getAttributes(WrapperIdentityStoreRepository.java:392) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.getAttributes(AttributesManagerImpl.java:194) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.updateAttributes(AttributesManagerImpl.java:255) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.updateAttributes(AttributesManagerImpl.java:280) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
at org.exoplatform.services.organization.idm.UserProfileDAOImpl.setProfile(UserProfileDAOImpl.java:259) [exo.portal.component.identity-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.exoplatform.services.organization.idm.UserProfileDAOImpl.saveUserProfile(UserProfileDAOImpl.java:97) [exo.portal.component.identity-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.gatein.security.oauth.data.SocialNetworkServiceImpl.updateOAuthInfo(SocialNetworkServiceImpl.java:136) [exo.portal.component.web.oauth-common-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.gatein.security.oauth.web.OAuthLinkAccountFilter.doFilter(OAuthLinkAccountFilter.java:91) [exo.portal.component.web.oauth-web-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.gatein.sso.integration.SSODelegateFilter$SSOFilterChain.doFilter(SSODelegateFilter.java:119) [sso-integration-1.3.4.Final-redhat-2.jar:1.3.4.Final-redhat-2]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-3284) Errors in saving long access-token for some social networks
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3284?page=com.atlassian.jira.pl... ]
Marek Posolda updated GTNPORTAL-3284:
-------------------------------------
Summary: Errors in saving long access-token for some social networks (was: Errors in saving long accessToken for some socialNetworks)
> Errors in saving long access-token for some social networks
> -----------------------------------------------------------
>
> Key: GTNPORTAL-3284
> URL: https://issues.jboss.org/browse/GTNPORTAL-3284
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.6.3.Final
> Reporter: Marek Posolda
> Assignee: Marek Posolda
> Fix For: 3.7.0.Final
>
>
> In some cases, it could happen that during binding of user to some social network (Facebook/Google/Twitter), the binding is not successful because of the fact that access token or refresh token is too long and DB throws error because of size limit of particular column (H2 has default limit of 255 characters per column)
> The exception stacktrace could look like this:
> {code}
> 12:06:50,595 WARN [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) SQL Error: 22001, SQLState: 22001
> 12:06:50,595 ERROR [org.hibernate.engine.jdbc.spi.SqlExceptionHelper] (http-/127.0.0.1:8080-3) Value too long for column "ATTR_VALUE VARCHAR(255)": "STRINGDECODE('VvjdI6prHvZXN6CG95jWIpkPLS0i6WMtitYVNeE8TRIfI3y+sCOxxJRqKIP9iCojWCajhup0QTro\nUe0YrgTbhKQbH7fMLEYOWKgtTNDt2omE5A0g... (259)"; SQL statement:
> insert into jbid_io_attr_text_values (TEXT_ATTR_VALUE_ID, ATTR_VALUE) values (?, ?) [22001-168]
> 12:06:50,597 INFO [org.exoplatform.services.organization.idm.UserProfileDAOImpl] (http-/127.0.0.1:8080-3) Identity operation error: : org.hibernate.exception.DataException: could not execute statement
> at org.hibernate.exception.internal.SQLStateConversionDelegate.convert(SQLStateConversionDelegate.java:134)
> at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:49)
> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:125)
> at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:110)
> at org.hibernate.engine.jdbc.internal.ResultSetReturnImpl.executeUpdate(ResultSetReturnImpl.java:136)
> at org.hibernate.engine.jdbc.batch.internal.NonBatchingBatch.addToBatch(NonBatchingBatch.java:58)
> at org.hibernate.persister.collection.AbstractCollectionPersister.insertRows(AbstractCollectionPersister.java:1474)
> at org.hibernate.action.internal.CollectionUpdateAction.execute(CollectionUpdateAction.java:86)
> at org.hibernate.engine.spi.ActionQueue.execute(ActionQueue.java:362)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:354)
> at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:278)
> at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:328)
> at org.hibernate.event.internal.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:62)
> at org.hibernate.internal.SessionImpl.autoFlushIfRequired(SessionImpl.java:1205)
> at org.hibernate.internal.SessionImpl.list(SessionImpl.java:1655)
> at org.hibernate.internal.CriteriaImpl.list(CriteriaImpl.java:374)
> at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getAttributes(HibernateIdentityStoreImpl.java:2108) [picketlink-idm-hibernate-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
> at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.getAttributes(WrapperIdentityStoreRepository.java:392) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
> at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.getAttributes(AttributesManagerImpl.java:194) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
> at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.updateAttributes(AttributesManagerImpl.java:255) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
> at org.picketlink.idm.impl.api.session.managers.AttributesManagerImpl.updateAttributes(AttributesManagerImpl.java:280) [picketlink-idm-core-1.4.3.Final-redhat-2.jar:1.4.3.Final-redhat-2]
> at org.exoplatform.services.organization.idm.UserProfileDAOImpl.setProfile(UserProfileDAOImpl.java:259) [exo.portal.component.identity-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.exoplatform.services.organization.idm.UserProfileDAOImpl.saveUserProfile(UserProfileDAOImpl.java:97) [exo.portal.component.identity-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.gatein.security.oauth.data.SocialNetworkServiceImpl.updateOAuthInfo(SocialNetworkServiceImpl.java:136) [exo.portal.component.web.oauth-common-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.gatein.security.oauth.web.OAuthLinkAccountFilter.doFilter(OAuthLinkAccountFilter.java:91) [exo.portal.component.web.oauth-web-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
> at org.gatein.sso.integration.SSODelegateFilter$SSOFilterChain.doFilter(SSODelegateFilter.java:119) [sso-integration-1.3.4.Final-redhat-2.jar:1.3.4.Final-redhat-2]
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-3283) Eliminate the Warning "JBAS018204: Clustering not supported, falling back to non-clustered session manager"
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3283?page=com.atlassian.jira.pl... ]
Marek Posolda commented on GTNPORTAL-3283:
------------------------------------------
Related classes DistributableSessionManager and JbossContextConfig are part of JBoss AS codebase (component jboss-as-web . It's the code for web clustering)
> Eliminate the Warning "JBAS018204: Clustering not supported, falling back to non-clustered session manager"
> -----------------------------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3283
> URL: https://issues.jboss.org/browse/GTNPORTAL-3283
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Packaging
> Reporter: Peter Palaga
> Assignee: Marko Strukelj
> Fix For: 3.7.0.Final
>
>
> There are two occurences of this warning in GateIn startup log on JBoss
> {code}
> 09:24:30,563 WARN [org.jboss.web] (MSC service thread 1-2) JBAS018204: Clustering not supported, falling back to non-clustered session manager
> 09:24:30,566 WARN [org.jboss.web] (MSC service thread 1-3) JBAS018204: Clustering not supported, falling back to non-clustered session manager
> 0
> {code}
> These warnings should be eliminated, if possible, as there should be no warnings during startup of an out of the box GateIn instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-3283) Eliminate the Warning "JBAS018204: Clustering not supported, falling back to non-clustered session manager"
by Marek Posolda (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3283?page=com.atlassian.jira.pl... ]
Marek Posolda commented on GTNPORTAL-3283:
------------------------------------------
Actually this is just a minor JBoss AS issue. I think there are these possibilities how to workaround it and remove warning:
1) Comment <distributable /> in gatein.ear/portal.war/WEB-INF/web.xml . As Marko mentioned, this will work, but it would require manual step for people who would like to add clustering. So not good solution.
2) Add/uncomment configuration of web cache container in infinispan subsystem in standalone.xml . This will fix the WARN message, but it's performance killer. See https://issues.jboss.org/browse/GTNPORTAL-3137 . IMO this is not an option as well because of performance.
(It's this snippet in standalone.xml . Note that it's commented just in JPP 6.1/JBoss AS 7.2.X or later, because in JBoss AS 7.1.X the configuration for the container is not in standalone.xml. It was added in JBoss AS 7.2) :
{code}
<!--Uncommented this if you want persistent HTTP sessions among server restarts (WARN: Performance penalty)-->
<!--
<cache-container name="web" aliases="standard-session-cache" default-cache="local-web" module="org.jboss.as.clustering.web.infinispan">
<local-cache name="local-web" batching="true">
<file-store passivation="false" purge="false"/>
</local-cache>
</cache-container>
-->
{code}
3) Have a better fix in JBoss AS itself. Actually the missing configuration of web container is causing that DistributableSessionManager throws NullPointerException and it's catched and logged as WARN in method JBossContextConfig.processWebMetaData() . Then it will fallback to default Tomcat StandardManager for handling HTTP sessions.
IMO the overall result is fine and WARN in server.log could be safely ignored. Only thing is that flow is little-bit strange (throwing NullPointerException and then catching is probably not the best way for handling things...
> Eliminate the Warning "JBAS018204: Clustering not supported, falling back to non-clustered session manager"
> -----------------------------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3283
> URL: https://issues.jboss.org/browse/GTNPORTAL-3283
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Packaging
> Reporter: Peter Palaga
> Assignee: Marko Strukelj
> Fix For: 3.7.0.Final
>
>
> There are two occurences of this warning in GateIn startup log on JBoss
> {code}
> 09:24:30,563 WARN [org.jboss.web] (MSC service thread 1-2) JBAS018204: Clustering not supported, falling back to non-clustered session manager
> 09:24:30,566 WARN [org.jboss.web] (MSC service thread 1-3) JBAS018204: Clustering not supported, falling back to non-clustered session manager
> 0
> {code}
> These warnings should be eliminated, if possible, as there should be no warnings during startup of an out of the box GateIn instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-3282) Eliminate the "using a private module org.apache.cxf:main" warning on JBoss startup
by Marko Strukelj (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3282?page=com.atlassian.jira.pl... ]
Marko Strukelj commented on GTNPORTAL-3282:
-------------------------------------------
This can be fixed by removing org.apache.cxf:main dependency from gatein-wsrp-integration.ear/*.war, and using GateIn subsystem to add it programatically.
The subsystem would have to be able to identify gatein-wsrp ear, and its children. That could be hardcoded by archive name or it could be based on some marker file that's only present in gatein-wsrp integration module.
> Eliminate the "using a private module org.apache.cxf:main" warning on JBoss startup
> -----------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3282
> URL: https://issues.jboss.org/browse/GTNPORTAL-3282
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: WSRP integration
> Reporter: Peter Palaga
> Assignee: Chris Laprun
> Fix For: 3.7.0.Final
>
>
> There are several warnings like this in GateIn startup log on JBoss:
> {code}
> 09:24:27,528 WARN [org.jboss.as.dependency.private] (MSC service thread 1-5) JBAS018567: Deployment "deployment.gatein-wsrp-integration.ear.extension-war.war" is using a private module ("org.apache.cxf:main") which may be changed or removed in future versions without notice.
> 09:24:27,551 WARN [org.jboss.as.dependency.private] (MSC service thread 1-4) JBAS018567: Deployment "deployment.gatein-wsrp-integration.ear.wsrp-admin-gui.war" is using a private module ("org.apache.cxf:main") which may be changed or removed in future versions without notice.
> 09:24:27,556 WARN [org.jboss.as.dependency.private] (MSC service thread 1-3) JBAS018567: Deployment "deployment.gatein-wsrp-integration.ear.wsrp-producer.war" is using a private module ("org.apache.cxf:main") which may be changed or removed in future versions without notice.
> 09:24:27,557 WARN [org.jboss.as.dependency.private] (MSC service thread 1-3) JBAS018567: Deployment "deployment.gatein-wsrp-integration.ear.wsrp-producer.war" is using a private module ("org.apache.cxf:main") which may be changed or removed in future versions without notice.
> 09:24:28,561 WARN [org.jboss.as.dependency.private] (MSC service thread 1-1) JBAS018567: Deployment "deployment.gatein-wsrp-integration.ear" is using a private module ("org.apache.cxf:main") which may be changed or removed in future versions without notice.
> {code}
> Searching for "org.apache.cxf" in GateIn source tree shows occurences in {{org.gatein.wsrp.integration}} {{module.xml}}: https://github.com/gatein/gatein-portal/blob/master/packaging/jboss-as7/m...
> These warning should be eliminated if possible as there should be no warnings in an out of the box GateIn installation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-3283) Eliminate the Warning "JBAS018204: Clustering not supported, falling back to non-clustered session manager"
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3283?page=com.atlassian.jira.pl... ]
Peter Palaga commented on GTNPORTAL-3283:
-----------------------------------------
Thanks for your comment, Marko. I vote for reporting this under the appropriate container project. Do you know which one is it?
> Eliminate the Warning "JBAS018204: Clustering not supported, falling back to non-clustered session manager"
> -----------------------------------------------------------------------------------------------------------
>
> Key: GTNPORTAL-3283
> URL: https://issues.jboss.org/browse/GTNPORTAL-3283
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Packaging
> Reporter: Peter Palaga
> Assignee: Marko Strukelj
> Fix For: 3.7.0.Final
>
>
> There are two occurences of this warning in GateIn startup log on JBoss
> {code}
> 09:24:30,563 WARN [org.jboss.web] (MSC service thread 1-2) JBAS018204: Clustering not supported, falling back to non-clustered session manager
> 09:24:30,566 WARN [org.jboss.web] (MSC service thread 1-3) JBAS018204: Clustering not supported, falling back to non-clustered session manager
> 0
> {code}
> These warnings should be eliminated, if possible, as there should be no warnings during startup of an out of the box GateIn instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-2072) NoSuchDataException is thrown after importing pages through export/import tool.
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-2072?page=com.atlassian.jira.pl... ]
Trong Tran updated GTNPORTAL-2072:
----------------------------------
Original Estimate: 1 day
Remaining Estimate: 1 day
> NoSuchDataException is thrown after importing pages through export/import tool.
> -------------------------------------------------------------------------------
>
> Key: GTNPORTAL-2072
> URL: https://issues.jboss.org/browse/GTNPORTAL-2072
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.0-Beta01
> Reporter: Nick Scavelli
> Assignee: Nick Scavelli
> Labels: import
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> Below exception is thrown after importing pages through management tools (see steps to reproduce section). I think this is a stale storageId coming from the UI when the data has changed outside the UI. Typically logging out solves the issue, but this isn't optimal. Changes to data should not be only achievable through the UI. The changes are being sent through DataStorage, so there should be someway to sync this data up.
> Stacktrace:
> {noformat}
> Caused by: org.exoplatform.portal.config.NoSuchDataException: Can not find 1c42bec77f0000011076449207f5d085
> at org.exoplatform.portal.pom.config.POMSession.findCustomizationById(POMSession.java:214)
> at org.exoplatform.portal.pom.config.tasks.PreferencesTask$Load.run(PreferencesTask.java:91)
> at org.exoplatform.portal.pom.config.POMSession.execute(POMSession.java:405)
> at org.exoplatform.portal.pom.config.ExecutorDispatcher.execute(ExecutorDispatcher.java:60)
> at org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
> at org.exoplatform.portal.pom.config.cache.DataCache.read(DataCache.java:169)
> at org.exoplatform.portal.pom.config.cache.DataCache.execute(DataCache.java:61)
> at org.exoplatform.portal.pom.config.TaskExecutionDecorator.execute(TaskExecutionDecorator.java:38)
> at org.exoplatform.portal.pom.config.cache.PortalNamesCache.execute(PortalNamesCache.java:77)
> at org.exoplatform.portal.pom.config.POMSessionManager.execute(POMSessionManager.java:251)
> at org.exoplatform.portal.pom.config.POMDataStorage.load(POMDataStorage.java:176)
> at org.exoplatform.portal.config.DataStorageImpl.load(DataStorageImpl.java:111)
> at org.exoplatform.portal.webui.application.ModelAdapter$1.getPortletContext(ModelAdapter.java:89)
> at org.exoplatform.portal.webui.application.UIPortlet.getPortletContext(UIPortlet.java:993)
> at org.exoplatform.portal.webui.application.UIPortlet.create(UIPortlet.java:829)
> at org.exoplatform.portal.webui.application.UIPortletLifecycle.processRender(UIPortletLifecycle.java:212)
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-511) userPref of gadgets are not sometime not saved correctly
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-511?page=com.atlassian.jira.plu... ]
Trong Tran updated GTNPORTAL-511:
---------------------------------
Original Estimate: 2 days (was: 3 days)
Remaining Estimate: 2 days (was: 3 days)
> userPref of gadgets are not sometime not saved correctly
> --------------------------------------------------------
>
> Key: GTNPORTAL-511
> URL: https://issues.jboss.org/browse/GTNPORTAL-511
> Project: GateIn Portal
> Issue Type: Bug
> Components: User Interface
> Affects Versions: 3.0.0-Beta04
> Environment: svn r1330
> Reporter: jerem j
> Assignee: Julien Viet
> Fix For: 3.5.7.Final
>
> Attachments: GTNPORTAL-511.js.patch, GTNPORTAL-511.patch, stacktrace.txt
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Every call to gadgets.Prefs.set generate a call to save the data in the backend (an action in the dashboard portlet). To save we send all the set of preferences.
> The jira gadget call this API multiple times in a very short time. So there is multiple ajax request sent to the backend but not in a precise order. So it might happen that the first request arrive the last one, and so old preferences are saved.
> To fix:
> In the file Gadgets.js, function "gadgets.IfrGadgetService.prototype.setUserPref", prefs is updated with all the name/value, and ALL the prefs object is saved. Instead of saving all the preferences, we should only save the updated preferences.
> In org.exoplatform.portal.pom.spi.gadget.Gadget it will be needed to be able to add preference by name, something like :
> public void setUserPref(String name, String value)
> code :
> Gadgets.js: http://fisheye.exoplatform.org/browse/projects/portal/trunk/web/eXoResour...
> ExoBasedUserPrefStore.js: http://fisheye.exoplatform.org/browse/projects/portal/trunk/web/eXoResour...
> links:
> API doc about adgets.Prefs.set: http://code.google.com/apis/gadgets/docs/reference/#gadgets.Prefs.set
> Jira gadget to test: http://jira4j.exoplatform.org/rest/gadgets/1.0/g/com.atlassian.jira.gadge...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-2899) The membership type "*" is not interpreted
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-2899?page=com.atlassian.jira.pl... ]
Trong Tran updated GTNPORTAL-2899:
----------------------------------
Remaining Estimate: 1 hour (was: 0 minutes)
> The membership type "*" is not interpreted
> -------------------------------------------
>
> Key: GTNPORTAL-2899
> URL: https://issues.jboss.org/browse/GTNPORTAL-2899
> Project: GateIn Portal
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5.3.Final
> Environment: eXo Platform 4.0.0-Beta2
> Reporter: Hela Zekri
> Assignee: Trong Tran
> Priority: Blocker
> Labels: portal-s71, worked
> Fix For: 3.7.0.Final
>
> Original Estimate: 4 hours
> Time Spent: 3 hours
> Remaining Estimate: 1 hour
>
> {color:red}
> In eXo Platform, we have the membership type "*". If user has this membership type in a group, it means that he has all membership types in this group.
> {color}
> *Please try this scenario :*
> Add a user that has the membership type "manager" in "/platform/administrators" group and the membership type "*" in "/platform/users" group.
> When this user clicks "add page" in "Page Management", he has the possibility to choose the owner type "group" or "portal". If he chooses "group", the expected output is that he gets as "Owner Id", a selectbox that contains all groups in which he has the membership type "manager".
> (!) The membership type "manager" is set in "portal-configuration.xml" as value-param to UserACL component :
> {code:xml}
> <value-param>
> <name>navigation.creator.membership.type</name>
> <description>specific membership type have full permission with group navigation</description>
> <value>manager</value>
> </value-param>
> {code}
> In this case, user should get as "Owner Id" a selectbox that contains "/platform/administrators" and "/platform/users" groups(The membership type "*" includes "manager" membership type).
> But the current behavior is that the selectbox of "Owner Id" contains only the group "/platform/administator". This is due to the fact that the relationship "*" is considered as a String and not interpreted.
> *There are two possible solutions to this problem :*
> 1- Set the possibility to put many values for "navigation.creator.membership.type" value-param. So that we could do for example :
> {code:xml}
> <value-param>
> <name>navigation.creator.membership.type</name>
> <description>specific membership type have full permission with group navigation</description>
> <value>*,manager</value>
> </value-param>
> {code}
> 2- In "_findRoles_" method in "_org.picketlink.idm.impl.api.session.managers.RoleManagerImpl_" class :
> In the code bellow, each relationship of a user is compared to roleType ("manager"). If it is equal, it will be added to the list that will be returned. So even "*" is compared to "manager", it is not equal, so it won't be added.
> {code}
> for (IdentityObjectRelationship relationship : relationships)
> {
> if (roleType != null)
> {
> if (roleType.getName().equals(relationship.getName()))
> {
> roles.add(new SimpleRole(new SimpleRoleType(relationship.getName()), createUser(relationship.getToIdentityObject()), createGroup(relationship.getFromIdentityObject())));
> }
> }
> else
> {
> roles.add(new SimpleRole(new SimpleRoleType(relationship.getName()), createUser(relationship.getToIdentityObject()), createGroup(relationship.getFromIdentityObject())));
> }
> }
> {code}
> We created [https://issues.jboss.org/browse/PLIDM-40] in which we propose a patch that adds a test on "*" value.
> In the patch, we changed :
> {code}
> if (roleType.getName().equals(relationship.getName()))
> {code}
> to :
> {code}
> if ((roleType.getName().equals(relationship.getName())) || relationship.getName().equals("*"))
> {code}
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (GTNPORTAL-3254) Configure Organization Service TCK tests for the PicketLink implementation
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3254?page=com.atlassian.jira.pl... ]
Trong Tran updated GTNPORTAL-3254:
----------------------------------
Sprint: Sprint 77, Sprint 78, Sprint 79, Sprint 81 (was: Sprint 77, Sprint 78, Sprint 79, Sprint 81, Sprint 83)
> Configure Organization Service TCK tests for the PicketLink implementation
> --------------------------------------------------------------------------
>
> Key: GTNPORTAL-3254
> URL: https://issues.jboss.org/browse/GTNPORTAL-3254
> Project: GateIn Portal
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Identity integration
> Reporter: Trong Tran
> Assignee: Tuyen Nguyen The
> Labels: backlogs
> Fix For: 3.7.0.Final
>
> Original Estimate: 1 day
> Time Spent: 1 day, 3 hours, 30 minutes
> Remaining Estimate: 2 hours
>
> Here is the link for org service TCK documentation : http://docs.jboss.org/exojcr/1.15.4-GA/developer/en-US/html_single/#Core....
> Some examples :
> https://github.com/exodev/core/blob/master/exo.core.component.organizatio...
> https://github.com/exodev/core/blob/master/exo.core.component.organizatio...
> https://github.com/exodev/jcr-services/blob/master/pom.xml
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months