[JBoss JIRA] (GTNPORTAL-3489) [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
by Trong Tran (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3489?page=com.atlassian.jira.pl... ]
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)
9 years, 10 months
[JBoss JIRA] (GTNPORTAL-3365) Exception swallow in UserDaoImpl.persistUserInfo()
by Tran Trung Thanh (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3365?page=com.atlassian.jira.pl... ]
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/a0d1948b437f585e1f757d244.... 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)
9 years, 10 months
[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 commented on GTNPORTAL-3502:
-----------------------------------------
Tests added https://github.com/gatein/gatein-portal/commit/d1c07e977c3a63d59fec686821...
> 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)
9 years, 10 months
[JBoss JIRA] (GTNPORTAL-3510) Possible memory leaks, consistency issues and concurrency issues in ScriptGraph
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3510?page=com.atlassian.jira.pl... ]
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/ab54bfc1489e73610845f9ce44...
> 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)
9 years, 10 months
[JBoss JIRA] (GTNPORTAL-3489) [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
by Ahmed Zaoui (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3489?page=com.atlassian.jira.pl... ]
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)
9 years, 10 months
[JBoss JIRA] (GTNPORTAL-3489) [MembershipDAOImpl]ORA-00001: unique constraint (IDM.SYS_C0015551) violated
by Ahmed Zaoui (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3489?page=com.atlassian.jira.pl... ]
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)
9 years, 10 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:
--------------------------------------------------
Tomas Kyjovsky <tkyjovsk(a)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@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)
9 years, 10 months
[JBoss JIRA] (GTNPORTAL-3506) Allow multiple apps registering the very same AMD paths
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3506?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-3506:
----------------------------------------------------
Peter Palaga <ppalaga(a)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)
9 years, 10 months