On 01/02/2013 13:42, Andrei Shakirin wrote:
Hi Francesco,

Not really :) I guess it happens just by chance ...

Well, a stable chance over time, then: I have no more failures with JDK 1.7 since yesterday afternoon, and I've been building the whole day so far...

I have committed workaround some minutes ago - it fixes at least my Windows 1.7 
build.
Could you please check under Linux after this commit?

As said above, it works.

Regards.

I have some ideas how to fix it more reliable, will write comment to 
SYNCOPE-298.

Regards,
Andrei.

-----Original Message-----
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Donnerstag, 31. Januar 2013 18:12
To: dev@syncope.apache.org
Subject: Re: Build not working (again) with JDK 1.7

Hi Andrei,
I just want to report that, after today's work, I am able to successfully build
with JDK 1.7 -  I guess you've found the way to cope with existing ids in the
test content.xml and the ids generated during test execution, nice!

Regards.

On 30/01/2013 13:43, Andrei Shakirin wrote:
Hi Francesco,

I have problem under jdk 1.7 as well, but in other test!

Running org.apache.syncope.core.rest.UserTestITCase
Tests run: 52, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
33.524 sec <<< FAILURE!

testEnforceMandatoryConditionOnDerived(org.apache.syncope.core.rest.U
s
erTestITCa
se)  Time elapsed: 0.172 sec  <<< ERROR!

org.apache.syncope.common.validation.SyncopeClientCompositeErrorExcep
t
ion: {[Dat aIntegrityViolation [The transaction has been rolled back.
See the nested excep tions for details on the errors that occurred.]]}

This problem is really related to SYNCOPE-298:

SEVERE: Servlet.service() for servlet [syncope-core-rest] in context with
path [/syncope] threw exception [Request processing failed; nested
exception is 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@3aa73b72]
with
root cause
org.apache.openjpa.lib.jdbc.ReportingSQLException: 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 178787393 INSERT INTO
PUBLIC.UVirAttr (ID, OWNER_ID, VIRTUALSCHEMA_NAME) VALUES (?, ?, ?)}
[code=23505, state=23505]
        at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConn
ectionDecorator.java:219)
        at

org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingCon
nectionDecorator.java:195)

Could you please experiment a little bit in your environment:
1. Check cargo-output.log for
org.apache.openjpa.persistence.EntityExistsException related to
org.apache.syncope.core.persistence.beans.user.UVirAttr
2. Run UserTestITCase and TaskITTestCase separately and check if
problems are still there.
?

Let see if it will be necessary to re-prioritize SYNCOPE-298.

Regards,
Andrei.

P.S: Task patch from SYNCOPE-231 has inserted @Ignored to 2
TaskTestITCase tests. I will care to enable them again.
-----Original Message-----
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Mittwoch, 30. Januar 2013 11:41
To: dev@syncope.apache.org
Subject: Build not working (again) with JDK 1.7

Hi all,
unfortunately, after latest updates since yesterday afternoon when I
did my last checks, the build on JDK 1.7 is failing again:

Results :

Failed tests:
     UserTestITCase.create:481 expected:<166> but was:<165>
     UserTestITCase.verifyTaskRegistration:1000 expected:<187> but
was:<186>

Tests in error:
     TaskTestITCase.sync:325 » SyncopeClientCompositeError {[NotFound
[User test0]]...


With JDK 1.6 no problems (as Jenkins confirms).

Both behaviours seems to be stable.

Andrei told me yesterday that this is not the case, but just for sake
of completeness, let's think again if this is related to SYNCOPE-298.

If not, what can be the reason of these failures with JDK 1.7?

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/


--
Francesco Chicchiriccò

ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/

Reply via email to