Hi Fabio,
Investigated a little bit more and found the following:
1. TimeoutException
> This is the expected exception: it should be handled and returned as a
> SyncopeClientErrorException.
Not really. As far as I can see TimeoutException thrown by
ConnectorFacadeProxy.getObject() is never wrapped to
SyncopeClientErrorException.
Check the whole chain: UserController.create() ->
UserController.createInternal() -> taskExecutor.execute() ->
PriorityPropagationTaskExecutor.execute() ->
AbstractPropagationTaskExecutor.getRemoteObject() ->
ConnectorFacadeProxy.getObject();
AbstractPropagationTaskExecutor.getRemoteObject() just re-throws the Timeout
exception.
syncopeClientError.jsp doesn't handle the TimeoutException and returns
InternalServerError that I get from my test.
That explains why this test doesn't work. Why it works during the build? - see
topic (2)
2. Why UserTestITCase. issueSYNCOPE279() works sometimes.
If UserTestITCase executed after some previous tests (or under some other
conditions: JDK, OS, etc), it throws other exception BEFORE execute the task:
18:23:41.946 ERROR org.apache.syncope.core.rest.controller.AbstractController -
Exception thrown by REST methods
org.springframework.dao.DataIntegrityViolationException: The transaction has
been rolled back. See the nested exceptions for details on the errors that
occurred.; nested exception is <openjpa-2.2.1-r422266:1396819 fatal store
error> org.apache.openjpa.persistence.EntityExistsException: The transaction
has been rolled back. See the nested exceptions for details on the errors that
occurred.
FailedObject: org.apache.syncope.core.persistence.beans.user.UVirAttr@cd0cca3
at
org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:313)
~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:121)
~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.orm.jpa.JpaTransactionManager.doCommit(JpaTransactionManager.java:517)
~[spring-orm-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.processCommit(AbstractPlatformTransactionManager.java:755)
~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.transaction.support.AbstractPlatformTransactionManager.commit(AbstractPlatformTransactionManager.java:724)
~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAspectSupport.java:387)
~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:120)
~[spring-tx-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
~[spring-aop-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
~[spring-aop-3.2.1.RELEASE.jar:3.2.1.RELEASE]
at $Proxy137.create(Unknown Source) ~[na:na]
at
org.apache.syncope.core.rest.controller.UserController.createInternal(UserController.java:306)
~[UserController.class:na]
at
org.apache.syncope.core.rest.controller.UserController.create(UserController.java:284)
~[UserController.class:na]
Caused by: org.apache.openjpa.persistence.EntityExistsException: Eindeutiger
Index oder Primärschlüssel verletzt: "PRIMARY_KEY_C4 ON PUBLIC.UVIRATTR(ID)"
Unique index or primary key violation: "PRIMARY_KEY_C4 ON PUBLIC.UVIRATTR(ID)";
SQL statement:
INSERT INTO PUBLIC.UVirAttr (ID, OWNER_ID, VIRTUALSCHEMA_NAME) VALUES (?, ?, ?)
[23505-170] {prepstmnt 2122205967 INSERT INTO PUBLIC.UVirAttr (ID, OWNER_ID,
VIRTUALSCHEMA_NAME) VALUES (?, ?, ?)} [code=23505, state=23505]
DataIntegrityViolationException is mapped to SyncopeClientCompositeError Type
header in syncopeClientError.jsp and interpreted as SCCEE on the client side.
Test is green just because this effect.
I think the reason of this DataIntegrityViolationException is AUTO generation
strategy in AbstractVirtualAttribute entity.
It seems that this test runs successfully only occasionally because of another
error.
Could you confirm my findings?
If yes, we should fix the following:
1. Map TimeoutException to SCCEE
2. Fix DataIntegrityViolationException for AbstractVirtualAttribute
Generally I would propose to design integration tests as independent as
possible. Dependencies between different test cases and individual tests makes
error analyse extreme difficult and time consuming. Ideally integration test
should leave environment unchanged or compensated.
WDYT?
Regards,
Andrei.
> -----Original Message-----
> From: Fabio Martelli [mailto:fabio.marte...@gmail.com]
> Sent: Montag, 28. Januar 2013 16:42
> To: dev@syncope.apache.org
> Subject: Re: [Question] Problem with test UsertTestITCase.issueSYNCOPE279
>
> Hi Andrei, answers and comment inline.
>
> Il giorno 28/gen/2013, alle ore 16.09, Andrei Shakirin ha scritto:
>
> > Hi,
> >
> > I am analysing problem regarding UsertTestITCase.issueSYNCOPE279().
> > It is reproducible in following situations:
> >
> > 1) Run it as single test: mvn -Pdev -DwaitForCheck=false -Dit.test=
> UserTestITCase# issueSYNCOPE279
>
> Wow, strange, I implemented using these options ...
>
> > Because of some reasons this test is succeed in case if
> AuthenticationTestITCase,ResourceTestITCase,RoleTestITCase,SchemaTestIT
> Case,UserRequestTestITCase were executed before (interesting :) )
>
> This is really strange. issueSYNCOPE279 shouldn't have any dependency.
> Please, take a look at the code: it simply create a new profile giving it an
> ad-
> hoc resource (never used before).
>
> > 2) If all core integration tests is running under JDK 1.7
> > 3) With some other conditions.
> >
> > My analysis shows that the end reason is that SOAP connector (using CXF
> client) receives HTML as response for test() invocation:
> >
> > 15:47:46.041 DEBUG
> org.identityconnectors.framework.api.operations.GetApiOp.getObject
> Exception:
> > javax.xml.ws.soap.SOAPFaultException: Response was of unexpected
> text/html ContentType. Incoming portion of HTML stream: OK
> > at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:156)
> ~[cxf-rt-frontend-jaxws-2.7.0.jar:2.7.0]
> > at $Proxy196.checkAlive(Unknown Source) ~[na:na]
> > at
> org.connid.bundles.soap.WebServiceConnection.test(WebServiceConnectio
> n.java:89) ~[na:na]
> > at
> org.connid.bundles.soap.WebServiceConnector.checkAlive(WebServiceCon
> nector.java:169) ~[na:na]
> > at
> org.identityconnectors.framework.impl.api.local.ConnectorPoolManager$Co
> nnectorPoolHandler.testObject(ConnectorPoolManager.java:105)
> ~[framework-internal-1.3.2.jar:na]
>
> This exception occurs after the Timeout. It is thrown by the "zombie" task.
>
> > Therefore propagation of resource "ws-target-resource-3" is failed with
> following error:
> >
> > 15:46:55.221 ERROR
> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
> r - Exception during provision on resource ws-target-resource-3
> > org.apache.syncope.core.propagation.TimeoutException: Request timeout
> > at
> org.apache.syncope.core.propagation.impl.ConnectorFacadeProxy.getObjec
> t(ConnectorFacadeProxy.java:380) ~[ConnectorFacadeProxy.class:na]
> > at
> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
> r.getRemoteObject(AbstractPropagationTaskExecutor.java:438)
> ~[AbstractPropagationTaskExecutor.class:na]
> > at
> org.apache.syncope.core.propagation.impl.AbstractPropagationTaskExecuto
> r.execute(AbstractPropagationTaskExecutor.java:288)
> ~[AbstractPropagationTaskExecutor.class:na]
>
> This is the expected exception: it should be handled and returned as a
> SyncopeClientErrorException.
>
> > Could you give a hint how to investigate this connector invocation error?
> > To which instance SOAP connector sends test() request? Why it sometimes
> answers with HTML?
>
> It is not a really soap resource: it is a servlet returning "OK" after a
> delay of 60
> seconds.
> Syncope shouldn't take care of the result because it comes after the timeout.
>
> Regards,
> F.
>
>
