[JBoss JIRA] (GTNPORTAL-3257) REST MOP Import doesn't detect errors on commit
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3257?page=com.atlassian.jira.pl... ]
Peter Palaga updated GTNPORTAL-3257:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 3.6.4.Final
3.7.0.Final
Resolution: Done
> REST MOP Import doesn't detect errors on commit
> -----------------------------------------------
>
> Key: GTNPORTAL-3257
> URL: https://issues.jboss.org/browse/GTNPORTAL-3257
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: REST API
> Affects Versions: 3.6.0.Final
> Reporter: Toshiya Kobayashi
> Assignee: Nick Scavelli
> Fix For: 3.6.4.Final, 3.7.0.Final
>
>
> When you call REST MOP Import:
> {noformat}
> curl -v -u root:gtn -X PUT -H 'Content-type: application/zip' --upload-file portal_classic_2013-06-10_15-16-53.zip http://localhost:8080/rest/private/managed-components/mop?importMode=over...
> {noformat}
> It returns 200 OK even if it fails on JCR commit (for example, cache replication timeout).
> Because JCR commit happens in RequestLifeCycle.end() after requestHandler.handleRequest() which flushes http response.
> https://github.com/exoplatform/ws/blob/master/exo.ws.rest.core/src/main/j...
> {code:java}
> protected void onService(ExoContainer container, HttpServletRequest httpRequest, HttpServletResponse httpResponse)
> throws IOException, ServletException
> {
> ...
> try
> {
> EnvironmentContext.setCurrent(env);
> ServletContainerRequest request = new ServletContainerRequest(httpRequest);
> ContainerResponse response = new ContainerResponse(new ServletContainerResponseWriter(httpResponse));
> requestHandler.handleRequest(request, response);
> }
> ...
> finally
> {
> EnvironmentContext.setCurrent(null);
> RequestLifeCycle.end();
> }
> }
> {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, 3 months
[JBoss JIRA] (GTNPORTAL-3310) Empty node mapping validation does not work on create
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3310?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration commented on GTNPORTAL-3310:
----------------------------------------------------
Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 998575|https://bugzilla.redhat.com/show_bug.cgi?id=998575] from MODIFIED to ON_QA
> Empty node mapping validation does not work on create
> -----------------------------------------------------
>
> Key: GTNPORTAL-3310
> URL: https://issues.jboss.org/browse/GTNPORTAL-3310
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: User Interface
> Affects Versions: 3.6.3.Final
> Reporter: Alexandre Mendonça
> Assignee: Alexandre Mendonça
> Fix For: 3.6.4.Final, 3.7.0.Final
>
>
> When you are adding new node mapping while editing existing redirect, and leave origin/redirect node mapping empty, you are allowed to save changes (but node mapping is not saved).
> When you are adding new node mapping in new redirect, and leave origin/redirect node mapping empty, after saving changes redirect is not created.
> Empty node validation works only when you already typed node name and then you erased it.
--
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, 3 months
[JBoss JIRA] (GTNPORTAL-3310) Empty node mapping validation does not work on create
by Peter Palaga (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3310?page=com.atlassian.jira.pl... ]
Peter Palaga updated GTNPORTAL-3310:
------------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 3.6.4.Final
3.7.0.Final
Resolution: Done
Merged last week.
> Empty node mapping validation does not work on create
> -----------------------------------------------------
>
> Key: GTNPORTAL-3310
> URL: https://issues.jboss.org/browse/GTNPORTAL-3310
> Project: GateIn Portal
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: User Interface
> Affects Versions: 3.6.3.Final
> Reporter: Alexandre Mendonça
> Assignee: Alexandre Mendonça
> Fix For: 3.6.4.Final, 3.7.0.Final
>
>
> When you are adding new node mapping while editing existing redirect, and leave origin/redirect node mapping empty, you are allowed to save changes (but node mapping is not saved).
> When you are adding new node mapping in new redirect, and leave origin/redirect node mapping empty, after saving changes redirect is not created.
> Empty node validation works only when you already typed node name and then you erased it.
--
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, 3 months
[JBoss JIRA] (GTNPORTAL-3342) SecureRandomGenerator instance per container requires too much entropy
by Marek Posolda (JIRA)
Marek Posolda created GTNPORTAL-3342:
----------------------------------------
Summary: SecureRandomGenerator instance per container requires too much entropy
Key: GTNPORTAL-3342
URL: https://issues.jboss.org/browse/GTNPORTAL-3342
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.6.4.Final, 3.7.0.Final
Currently every portal container instance uses it's own instance of SecureRandomGenerator for generating password salts. This requires too much entropy if many containers are used (50).
In QA lab environment, registering new generator freezes portal boot for roughly 20-30s (1 min 40s max).
--
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, 3 months
[JBoss JIRA] (GTNPORTAL-3341) Cannot delete users with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/GTNPORTAL-3341?page=com.atlassian.jira.pl... ]
RH Bugzilla Integration updated GTNPORTAL-3341:
-----------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038482
> 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.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 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, 3 months
[JBoss JIRA] (GTNPORTAL-3341) Cannot delete users with OracleDB because of "ORA-02292: integrity constraint (XXXXX) violated"
by Marek Posolda (JIRA)
Marek Posolda created GTNPORTAL-3341:
----------------------------------------
Summary: 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.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 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, 3 months