Hi Francesco, Not really :) I guess it happens just by chance ... 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?
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/
