Il giorno 28/gen/2013, alle ore 18.54, Andrei Shakirin ha scritto:
> 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.
Hi Andrei, I found the problem: into the AbstractPropagationTaskExecutor, line
334, the call to getRemoteObject have to be encapsulated into a try-catch body.
As you can see, this is not an issue related to the TimeoutException only but
it is an issue of the whole propagation process.
TimeoutException (or whatever specific propagation exception) won't be never
thrown ...
Let me take care of this particular fix.
> 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:
This is terrible: why the creation of a new virtual attribute should fail?
Doesn't UVirAttr id auto generation work fine anymore?
Can you investigate more?
> 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.
>>
>>
>
