July 2014 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3525) JTA - HibernateException: Unable to locate current JTA transaction

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3525?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated GTNPORTAL-3525: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1122138 > JTA - HibernateException: Unable to locate current JTA transaction > ------------------------------------------------------------------ > > Key: GTNPORTAL-3525 > URL: https://issues.jboss.org/browse/GTNPORTAL-3525 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.8.2.Final > Reporter: Marek Posolda > Assignee: Marek Posolda > Fix For: 3.8.3.Final, 3.9.0.Final > > > See https://bugzilla.redhat.com/show_bug.cgi?id=1122138 . Snipet from tacktrace: > {code} > [0m08:24:01,660 INFO [org.exoplatform.services.organization.idm.UserDAOImpl] (http-vmg39.mw.lab.eng.bos.redhat.com/10.16.88.117:8080-5) Cannot obtain user: john; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2798) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2850) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObject(HibernateIdentityStoreImpl.java:2896) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.safeGet(HibernateIdentityStoreImpl.java:2821) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:684) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:171) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.exoplatform.services.organization.idm.UserDAOImpl.getPopulatedUser(UserDAOImpl.java:727) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1] > at org.exoplatform.services.organization.idm.UserDAOImpl.findUserByName(UserDAOImpl.java:294) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1] > at org.exoplatform.web.login.FilterDisabledLoginModule.login(FilterDisabledLoginModule.java:72) [exo.portal.component.web.security-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1] > ... > Caused by: org.hibernate.HibernateException: Unable to locate current JTA transaction > at org.hibernate.context.internal.JTASessionContext.currentSession(JTASessionContext.java:89) > at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:993) > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.getSessionContext(HibernateIdentityStoreSessionImpl.java:57) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2789) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] > ... 89 more > {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3525) JTA - HibernateException: Unable to locate current JTA transaction

by Marek Posolda (JIRA)

Marek Posolda created GTNPORTAL-3525: ---------------------------------------- Summary: JTA - HibernateException: Unable to locate current JTA transaction Key: GTNPORTAL-3525 URL: https://issues.jboss.org/browse/GTNPORTAL-3525 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 3.8.2.Final Reporter: Marek Posolda Assignee: Marek Posolda Fix For: 3.8.3.Final, 3.9.0.Final See https://bugzilla.redhat.com/show_bug.cgi?id=1122138 . Snipet from tacktrace: {code} [0m08:24:01,660 INFO [org.exoplatform.services.organization.idm.UserDAOImpl] (http-vmg39.mw.lab.eng.bos.redhat.com/10.16.88.117:8080-5) Cannot obtain user: john; : org.picketlink.idm.common.exception.IdentityException: Cannot obtain Hibernate Session at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2798) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObjectType(HibernateIdentityStoreImpl.java:2850) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateIdentityObject(HibernateIdentityStoreImpl.java:2896) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.safeGet(HibernateIdentityStoreImpl.java:2821) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.findIdentityObject(HibernateIdentityStoreImpl.java:684) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.findIdentityObject(WrapperIdentityStoreRepository.java:171) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.findUser(PersistenceManagerImpl.java:426) [picketlink-idm-core-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.exoplatform.services.organization.idm.UserDAOImpl.getPopulatedUser(UserDAOImpl.java:727) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1] at org.exoplatform.services.organization.idm.UserDAOImpl.findUserByName(UserDAOImpl.java:294) [exo.portal.component.identity-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1] at org.exoplatform.web.login.FilterDisabledLoginModule.login(FilterDisabledLoginModule.java:72) [exo.portal.component.web.security-3.8.4.Final-redhat-1.jar:3.8.4.Final-redhat-1] ... Caused by: org.hibernate.HibernateException: Unable to locate current JTA transaction at org.hibernate.context.internal.JTASessionContext.currentSession(JTASessionContext.java:89) at org.hibernate.internal.SessionFactoryImpl.getCurrentSession(SessionFactoryImpl.java:993) at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreSessionImpl.getSessionContext(HibernateIdentityStoreSessionImpl.java:57) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.getHibernateSession(HibernateIdentityStoreImpl.java:2789) [picketlink-idm-hibernate-1.4.5.Final-redhat-1.jar:1.4.5.Final-redhat-1] ... 89 more {code} -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.pl... ] Juraci Paixão Kröhling commented on GTNPORTAL-3524: --------------------------------------------------- I've just submitted another set of branches for a more permanent solution. Note that this needs to be verified and validated by QE, but would be interesting to get the customer's feedback as well (after QE runs at least a smoke test). Branches: https://github.com/jpkrohling/gatein-portal/tree/BZ1122527-ConsumerOnCust... https://github.com/jpkrohling/gatein-wsrp/tree/BZ1122527-ConsumerOnCustom... > Custom portals cannot use remote portlets > ----------------------------------------- > > Key: GTNPORTAL-3524 > URL: https://issues.jboss.org/browse/GTNPORTAL-3524 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WSRP integration > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. > This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . > With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. > With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. > While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3524?page=com.atlassian.jira.pl... ] Juraci Paixão Kröhling commented on GTNPORTAL-3524: --------------------------------------------------- I'm still working on getting a proper fix for this, but in the meantime, I'll make the quick workarounds available: First workaround - add a configuration option to specify on which portal to bind the consumers to. The option is {code}gatein.wsrp.consumer.bindToPortalName{code} and should be added to {code}standalone/configuration/gatein/configuration.properties{code}. Branch for this workaround: https://github.com/jpkrohling/gatein-portal/tree/BZ1122527-ConsumerOnCust... > Custom portals cannot use remote portlets > ----------------------------------------- > > Key: GTNPORTAL-3524 > URL: https://issues.jboss.org/browse/GTNPORTAL-3524 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: WSRP integration > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. > This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . > With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. > With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. > While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3524) Custom portals cannot use remote portlets

by Juraci Paixão Kröhling (JIRA)

Juraci Paixão Kröhling created GTNPORTAL-3524: ------------------------------------------------- Summary: Custom portals cannot use remote portlets Key: GTNPORTAL-3524 URL: https://issues.jboss.org/browse/GTNPORTAL-3524 Project: GateIn Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: WSRP integration Reporter: Juraci Paixão Kröhling Assignee: Juraci Paixão Kröhling Before GTNPORTAL-3291, the FederatingPortletInvoker was shared among all contexts, meaning that a PortletInvoker responsible for local portlets was the same on "portal" and on "sample-portal". Similarly, a WSRP PortletInvoker was also shared. This caused the problems described in 3291 and 2700 and a fix was issued in that each context would have it's own FederatingPortletInvoker . With local portlets, each context having its own FederatingPortletInvoker is not a big issue, because the query is made at the JCR level for which portlets are available. With remote portlets, it's a problem, as WSRP registers the consumers only once, for the "portal" context. This means that the consumer invokers are not available for non-"portal" contexts. With this, a call from the context "sample-portal" to the FederatingPortletInvoker, requesting portlet "selfv2.bla" would fail, as there's no way to find this portlet on this particular invoker tree. While the producers are also started for the "portal" context, the fact that producers have their own servlet context makes it immune from this bug, as all HTTP calls to the producers reaches a context whose invoker *knows* about the requested portlet. In other words: producers are not affected by this bug. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3523) Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3523?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated GTNPORTAL-3523: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1117945 > Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data > ------------------------------------------------------------------------------------------------------------------------------ > > Key: GTNPORTAL-3523 > URL: https://issues.jboss.org/browse/GTNPORTAL-3523 > Project: GateIn Portal > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Packaging > Affects Versions: 3.8.4.Final > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.8.5.Final, 3.9.0.Final > > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1117945 > In EAP 6.3.0.ER8 (present in JBoss Portal 6.2.0.ER4) there is new class in jboss.as.controller: BlockingTimeout. > This class loads value of system property "jboss.as.management.blocking.timeout" or defaults to 300 (seconds). > This will cause a problem during portal startup if for any reason (more data, slower db) it takes more than 5 minutes. > How reproducible: > with more data (e.g. with >1000 users) > Steps to Reproduce: > 1. create a circumstance where portal startup takes longer than 5 minutes > 2. start portal > Actual results: > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[ > ("core-service" => "management"), > ("management-interface" => "native-interface") > ]' > After that the container is shut down. > Expected results: > Portal has enough time to start up. > Additional info: > The value of "jboss.as.management.blocking.timeout" property can be set to higher value. This should be either documented as workaround or it should be increased in portal configuration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3523) Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data

by Peter Palaga (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3523?page=com.atlassian.jira.pl... ] Peter Palaga commented on GTNPORTAL-3523: ----------------------------------------- Fixed in master https://github.com/gatein/gatein-portal/commit/78b37121ebf9c89f4fa696387d... and 3.8.x https://github.com/gatein/gatein-portal/commit/78b37121ebf9c89f4fa696387d... > Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data > ------------------------------------------------------------------------------------------------------------------------------ > > Key: GTNPORTAL-3523 > URL: https://issues.jboss.org/browse/GTNPORTAL-3523 > Project: GateIn Portal > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Packaging > Affects Versions: 3.8.4.Final > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.8.5.Final, 3.9.0.Final > > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1117945 > In EAP 6.3.0.ER8 (present in JBoss Portal 6.2.0.ER4) there is new class in jboss.as.controller: BlockingTimeout. > This class loads value of system property "jboss.as.management.blocking.timeout" or defaults to 300 (seconds). > This will cause a problem during portal startup if for any reason (more data, slower db) it takes more than 5 minutes. > How reproducible: > with more data (e.g. with >1000 users) > Steps to Reproduce: > 1. create a circumstance where portal startup takes longer than 5 minutes > 2. start portal > Actual results: > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[ > ("core-service" => "management"), > ("management-interface" => "native-interface") > ]' > After that the container is shut down. > Expected results: > Portal has enough time to start up. > Additional info: > The value of "jboss.as.management.blocking.timeout" property can be set to higher value. This should be either documented as workaround or it should be increased in portal configuration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3523) Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data

by Peter Palaga (JIRA)

Peter Palaga created GTNPORTAL-3523: --------------------------------------- Summary: Default value of property "jboss.as.management.blocking.timeout" (300 s) may be insufficient for portal startup with more data Key: GTNPORTAL-3523 URL: https://issues.jboss.org/browse/GTNPORTAL-3523 Project: GateIn Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Packaging Affects Versions: 3.8.4.Final Reporter: Peter Palaga Assignee: Peter Palaga Fix For: 3.8.5.Final, 3.9.0.Final Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1117945 In EAP 6.3.0.ER8 (present in JBoss Portal 6.2.0.ER4) there is new class in jboss.as.controller: BlockingTimeout. This class loads value of system property "jboss.as.management.blocking.timeout" or defaults to 300 (seconds). This will cause a problem during portal startup if for any reason (more data, slower db) it takes more than 5 minutes. How reproducible: with more data (e.g. with >1000 users) Steps to Reproduce: 1. create a circumstance where portal startup takes longer than 5 minutes 2. start portal Actual results: ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS013412: Timeout after [300] seconds waiting for service container stability. Operation will roll back. Step that first updated the service container was 'add' at address '[ ("core-service" => "management"), ("management-interface" => "native-interface") ]' After that the container is shut down. Expected results: Portal has enough time to start up. Additional info: The value of "jboss.as.management.blocking.timeout" property can be set to higher value. This should be either documented as workaround or it should be increased in portal configuration. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-2103) Can't delete an user with Oracle database

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-2103?page=com.atlassian.jira.pl... ] Trong Tran resolved GTNPORTAL-2103. ----------------------------------- Resolution: Duplicate Issue > Can't delete an user with Oracle database > ----------------------------------------- > > Key: GTNPORTAL-2103 > URL: https://issues.jboss.org/browse/GTNPORTAL-2103 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Identity integration > Affects Versions: 3.2.0-M01 > Environment: oracle-xe_10.2.0.1-1.0, GateIn revision 7347 > Reporter: kien nguyen > Assignee: Boleslaw Dawidowicz > Attachments: gatein2011-09-16.log > > > If an Oracle database is used, we can not delete an user with the organization portlet. > How to reproduced: > * connect to root/gtn. > * add new user. > * try to delete an user (has just been created) with the organization portlet-> exception > See error in log file -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3341) Cannot delete users with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"

by Trong Tran (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3341?page=com.atlassian.jira.pl... ] Trong Tran updated GTNPORTAL-3341: ---------------------------------- Fix Version/s: 3.5.11.Final > Cannot delete users with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated" > ----------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3341 > URL: https://issues.jboss.org/browse/GTNPORTAL-3341 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Identity integration > Affects Versions: 3.6.3.Final > Reporter: Marek Posolda > Assignee: Marek Posolda > Fix For: 3.5.11.Final, 3.6.4.Final, 3.7.0.Final > > > Description of problem: > Cannot delete users with OracleDB (reproducible at least on version 11gR2) because of "ORA-02292: integrity constraint (XXXXX) violated - child record found"[1]. The child record is in the JBID_IO_ATTR table[2]. > [1] > 2013-12-05 15:40:25,846 DEBUG [org.hibernate.util.JDBCExceptionReporter] (http-127.0.0.1-8080-1) Could not execute JDBC batch update [delete from jbid_io where ID=?] > java.sql.BatchUpdateException: ORA-02292: integrity constraint (ORAUSER.FK4DC61D7E992317F0) violated - child record found > at oracle.jdbc.driver.OraclePreparedStatement.executeBatch(OraclePreparedStatement.java:10345) > at oracle.jdbc.driver.OracleStatementWrapper.executeBatch(OracleStatementWrapper.java:230) > at org.jboss.resource.adapter.jdbc.CachedPreparedStatement.executeBatch(CachedPreparedStatement.java:476) > at org.jboss.resource.adapter.jdbc.WrappedStatement.executeBatch(WrappedStatement.java:774) > at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:70) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:268) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:265) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:171) > 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:1030) > at sun.reflect.GeneratedMethodAccessor346.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:343) > at com.sun.proxy.$Proxy266.flush(Unknown Source) > at org.picketlink.idm.impl.store.hibernate.HibernateIdentityStoreImpl.removeIdentityObject(HibernateIdentityStoreImpl.java:622) > at org.picketlink.idm.impl.repository.WrapperIdentityStoreRepository.removeIdentityObject(WrapperIdentityStoreRepository.java:158) > at org.picketlink.idm.impl.api.session.managers.PersistenceManagerImpl.removeUser(PersistenceManagerImpl.java:231) > at org.exoplatform.services.organization.idm.UserDAOImpl.removeUser(UserDAOImpl.java:268) > [2] > JBID_IO_ATTR: > ATTRIBUTE_ID 423 > IDENTITY_OBJECT_ID 413 > NAME user.language > ATTRIBUTE_TYPE text > BIN_VALUE_ID NULL > How reproducible: 100 % > Steps to Reproduce: > 1. Change gatein-idm and gatein-jcr to use OracleDB. > 2. Start EPP > 3. Login as root > 4. Create a user > 5. Delete the user > Actual results: > Cannot delete the user. > Expected results: > The user is deleted. > Additional info: > Some user attributes are deleted, so this process is not transactional. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues July 2014