[DISCUSSION] Integration tests instability causes by Ids collision (AUTO generation strategy)
Hi, Analyses shows, that real reason of failed/unstable tests is not AUTO generation strategy itself as reported in [1], but collision between newly created and pre-configured entries. Actually following entities have AUTO generation strategy: - AbstractDerAttr - AbstractVirAttr - Notification - UserRequest - UAttr I propose tree possible ways to fix the problem: A) Increase Id of corresponded pre-configured entities to large number (>1000) to make collision non probable. B) Avoid pre-configured objects for all entities with AUTO generation strategy. Redesign tests to create necessary data on the fly C) Change AUTO generation strategy to TABLE one. (A) is easiest, but looks like workaround for me. (B) sounds as the most reasonable. (C) is possible, but requires change in persistence strategy just because of tests (not the best practice) WDYT? Regards, Andrei. [1] https://issues.apache.org/jira/browse/SYNCOPE-298
[jira] [Resolved] (SYNCOPE-289) Prepare CXF Rest integration tests migration
[ https://issues.apache.org/jira/browse/SYNCOPE-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin resolved SYNCOPE-289. - Resolution: Fixed > Prepare CXF Rest integration tests migration > > > Key: SYNCOPE-289 > URL: https://issues.apache.org/jira/browse/SYNCOPE-289 > Project: Syncope > Issue Type: Sub-task > Components: console, core >Reporter: Andrei Shakirin >Assignee: Andrei Shakirin > Fix For: 1.1.0 > > > Moving back to 1.1.0 -- 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
Re: [DISCUSSION] Integration tests instability causes by Ids collision (AUTO generation strategy)
On 02/02/2013 10:10, Andrei Shakirin wrote: Hi, Analyses shows, that real reason of failed/unstable tests is not AUTO generation strategy itself as reported in [1], but collision between newly created and pre-configured entries. Actually following entities have AUTO generation strategy: - AbstractDerAttr - AbstractVirAttr - Notification - UserRequest - UAttr I propose tree possible ways to fix the problem: A) Increase Id of corresponded pre-configured entities to large number (>1000) to make collision non probable. B) Avoid pre-configured objects for all entities with AUTO generation strategy. Redesign tests to create necessary data on the fly C) Change AUTO generation strategy to TABLE one. (A) is easiest, but looks like workaround for me. (B) sounds as the most reasonable. (C) is possible, but requires change in persistence strategy just because of tests (not the best practice) Hi Andrei, first of all, thanks for caring about this! I agree with you that (A) is easy and sounds like a workaround but... we're talking about test data, hence workarounds don't smell like as usual :-) IMO, relying upon some default test data is actually very comfortable, so I wouldn't opt for (B). I agree with you about (C) : would this mean that SYNCOPE-298 could be marked as invalid at the end of the current discussion? Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-298 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: IncompatiblePolicyException was made unchecked
On 01/02/2013 17:44, Andrei Shakirin wrote: Can we agree on something here? My +1 for checked +1 from me as well. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
RE: [DISCUSSION] Integration tests instability causes by Ids collision (AUTO generation strategy)
Hi Francesco, > I agree with you that (A) is easy and sounds like a workaround but... > we're talking about test data, hence workarounds don't smell like as usual :-) > IMO, relying upon some default test data is actually very comfortable, so I > wouldn't opt for (B). Hmm ... for sure quality of tests data should not be on the same level as product/project data. But to be honest I am a little bit scared about side effects in integration tests - sometimes problems were caused by patches that not related with problem at all - very difficult to analyse and debug. I generally will vote to make integration tests more isolated, independent and reliable. Of course it will not happens in one day. So my +1 still for option (B) if it is doesn't require huge efforts (we should do it only for 5 entities, not for all). > I agree with you about (C) : would this mean that SYNCOPE-298 could be > marked as invalid at the end of the current discussion? Yep. I will close it. Cheers, Andrei. > -Original Message- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: Samstag, 2. Februar 2013 11:26 > To: dev@syncope.apache.org > Subject: Re: [DISCUSSION] Integration tests instability causes by Ids > collision > (AUTO generation strategy) > > On 02/02/2013 10:10, Andrei Shakirin wrote: > > Hi, > > > > Analyses shows, that real reason of failed/unstable tests is not AUTO > generation strategy itself as reported in [1], but collision between newly > created and pre-configured entries. > > Actually following entities have AUTO generation strategy: > > - AbstractDerAttr > > - AbstractVirAttr > > - Notification > > - UserRequest > > - UAttr > > > > I propose tree possible ways to fix the problem: > > A) Increase Id of corresponded pre-configured entities to large number > (>1000) to make collision non probable. > > B) Avoid pre-configured objects for all entities with AUTO generation > > strategy. Redesign tests to create necessary data on the fly > > C) Change AUTO generation strategy to TABLE one. > > > > (A) is easiest, but looks like workaround for me. (B) sounds as the > > most reasonable. (C) is possible, but requires change in persistence > > strategy just because of tests (not the best practice) > > Hi Andrei, > first of all, thanks for caring about this! > > I agree with you that (A) is easy and sounds like a workaround but... > we're talking about test data, hence workarounds don't smell like as usual :-) > > IMO, relying upon some default test data is actually very comfortable, so I > wouldn't opt for (B). > > I agree with you about (C) : would this mean that SYNCOPE-298 could be > marked as invalid at the end of the current discussion? > > Regards. > > > [1] https://issues.apache.org/jira/browse/SYNCOPE-298 > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/
Re: IncompatiblePolicyException was made unchecked
Basically I prefer unchecked but this would rather be a general change to not use checked exceptions at all. I do not insist on this style though and will go with the majority. Christian Am 02.02.2013 11:26, schrieb Francesco Chicchiriccò: On 01/02/2013 17:44, Andrei Shakirin wrote: Can we agree on something here? My +1 for checked +1 from me as well. Regards. -- Christian Schneider http://www.liquid-reality.de Open Source Architect Talend Application Integration Division http://www.talend.com
[Report] CXF migration status
Hi, Would like to shortly report status of CXF migration: It is basically finished. We still have 2 Failures and 4 Errors in JAXRS tests - it should be fixed in next days (the reason of two is already clear). Still open for 1.1.0 (SYNCOPE -231): 1) Fix rest errors in tests (6) 2) Finishing documentation 3) Configure (but not activate) CXF client for console 4) Release Notes Open for 1.2.0: 1) Final review of REST interfaces 2) Clean Spring MVC interfaces, proxies and tests 3) Uncomment Jackson annotations for abstract types 4) Activate CXF client in console 5) Release Notes Cheers, Andrei. P.S: I will not be active next two weeks because of vacation. See you again at the end of February.
[jira] [Closed] (SYNCOPE-298) Persistence beans: change AUTO Id generation strategy to TABLE
[ https://issues.apache.org/jira/browse/SYNCOPE-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Shakirin closed SYNCOPE-298. --- Resolution: Won't Fix Wouldn't be fixed because of another solution with pre-configured IDs is found > Persistence beans: change AUTO Id generation strategy to TABLE > -- > > Key: SYNCOPE-298 > URL: https://issues.apache.org/jira/browse/SYNCOPE-298 > Project: Syncope > Issue Type: Improvement > Components: core >Reporter: Andrei Shakirin > Fix For: 1.2.0 > > > Currently AUTO Id generation strategy works unstable under high > load/concurrency conditions at least for H2 DB. [1], [2] > Possible solution of this problem is migration AUTO to TABLE Id generation > strategy for all persistence domain objects. > [1] > http://syncope-dev.1063484.n5.nabble.com/Question-Problem-with-test-UsertTestITCase-issueSYNCOPE279-tt5712389.html > [2] > http://syncope-dev.1063484.n5.nabble.com/Persistence-id-generation-strategy-TABLE-vs-AUTO-td5711813.html -- 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
Re: [DISCUSSION] Integration tests instability causes by Ids collision (AUTO generation strategy)
On 02/02/2013 11:58, Andrei Shakirin wrote: Hi Francesco, I agree with you that (A) is easy and sounds like a workaround but... we're talking about test data, hence workarounds don't smell like as usual :-) IMO, relying upon some default test data is actually very comfortable, so I wouldn't opt for (B). Hmm ... for sure quality of tests data should not be on the same level as product/project data. But to be honest I am a little bit scared about side effects in integration tests - sometimes problems were caused by patches that not related with problem at all - very difficult to analyse and debug. I generally will vote to make integration tests more isolated, independent and reliable. Of course it will not happens in one day. So my +1 still for option (B) if it is doesn't require huge efforts (we should do it only for 5 entities, not for all). Andrei, there is an additional point I haven't reported so far to justify my preference for (A), e.g. embedded mode / standalone distribution. These are based on test data, so generating some of these only during actual test execution would result in some poorer user experience for users approaching Syncope for the first times. In this direction it is also to consider SYNCOPE-265 that will improve the quality of test data for such purpose. On the other side, maintaining two separate data sets (for tests and for embedded / standalone) would be a considerable effort that we can save. Regards. I agree with you about (C) : would this mean that SYNCOPE-298 could be marked as invalid at the end of the current discussion? Yep. I will close it. Cheers, Andrei. -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Samstag, 2. Februar 2013 11:26 To: dev@syncope.apache.org Subject: Re: [DISCUSSION] Integration tests instability causes by Ids collision (AUTO generation strategy) On 02/02/2013 10:10, Andrei Shakirin wrote: Hi, Analyses shows, that real reason of failed/unstable tests is not AUTO generation strategy itself as reported in [1], but collision between newly created and pre-configured entries. Actually following entities have AUTO generation strategy: - AbstractDerAttr - AbstractVirAttr - Notification - UserRequest - UAttr I propose tree possible ways to fix the problem: A) Increase Id of corresponded pre-configured entities to large number (>1000) to make collision non probable. B) Avoid pre-configured objects for all entities with AUTO generation strategy. Redesign tests to create necessary data on the fly C) Change AUTO generation strategy to TABLE one. (A) is easiest, but looks like workaround for me. (B) sounds as the most reasonable. (C) is possible, but requires change in persistence strategy just because of tests (not the best practice) Hi Andrei, first of all, thanks for caring about this! I agree with you that (A) is easy and sounds like a workaround but... we're talking about test data, hence workarounds don't smell like as usual :-) IMO, relying upon some default test data is actually very comfortable, so I wouldn't opt for (B). I agree with you about (C) : would this mean that SYNCOPE-298 could be marked as invalid at the end of the current discussion? Regards. [1] https://issues.apache.org/jira/browse/SYNCOPE-298 -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: [Report] CXF migration status
On 02/02/2013 12:07, Andrei Shakirin wrote: Hi, Would like to shortly report status of CXF migration: It looks very nice, thanks for reporting. As already said before, your (and the whole "CXF" team's) contribution has been very important and brought this project to a higher level in terms of activity, involvement, community growing, etc. I think now we just have to focus on some refinements - that will take some time, tough - before start discussing about releasing this feature-rich release 1.1.0. Have a nice holiday (Andrei) and WE (the rest of the crew). Regards. It is basically finished. We still have 2 Failures and 4 Errors in JAXRS tests - it should be fixed in next days (the reason of two is already clear). Still open for 1.1.0 (SYNCOPE -231): 1) Fix rest errors in tests (6) 2) Finishing documentation 3) Configure (but not activate) CXF client for console 4) Release Notes Open for 1.2.0: 1) Final review of REST interfaces 2) Clean Spring MVC interfaces, proxies and tests 3) Uncomment Jackson annotations for abstract types 4) Activate CXF client in console 5) Release Notes Cheers, Andrei. P.S: I will not be active next two weeks because of vacation. See you again at the end of February. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
