Closed peter-empen closed 6 years ago
Is it the case with 3.9.x
and 4.0.0.x
? Which version are you using please?
This is probably in both and a bug...
This is the case with 3.8.9 and before.
I'm sorry but I cannot reproduce with 4.0.0-RC2
and I don't think that version changed anything. Can you please test with that version and if you can reproduce, create a small github project showing the issue? Thanks.
How did you try to reproduce it?
A println in the SpecificationFinderSpec
and run example n.4
Thank you. Please bear with me for further investigations.
Any news for this?
Sorry, it'll take another 10 days until I manage to get down to this.
I created a small SBT project but have not yet managed to reproduce the issue in isolation. Since we are invoking different finders with different filter conditions, I now suspect that a Spec could be found twice due to some overlapping conditions. Would that explain duplicate instantiation?
This could be the reason yes. Maybe you can fire up your code in a debugger, step through and see what's going on?
Closing since it needs more investigation on our side and specs2 is possibly not responsible for the issue. I'll get back to you if I have any finding relevant for you.
Ok, thanks.
I've just spotted a stack trace giving more insight into how this occurs:
at org.specs2.reflect.Classes.$anonfun$createInstanceForConstructor$1(Classes.scala:61)
at org.specs2.reflect.Classes.newInstance(Classes.scala:83)
at org.specs2.reflect.Classes.createInstanceForConstructor(Classes.scala:61)
at org.specs2.reflect.Classes.findInstance(Classes.scala:47)
at org.specs2.reflect.Classes.createInstanceFromClass(Classes.scala:29)
at org.specs2.reflect.Classes.createInstanceFromClass$(Classes.scala:28)
at org.specs2.reflect.Classes$.createInstanceFromClass(Classes.scala:109)
at org.specs2.reflect.Classes.$anonfun$createInstance$1(Classes.scala:25)
at org.specs2.control.eff.Arrs.go$1(Eff.scala:385)
at org.specs2.control.eff.Arrs.apply(Eff.scala:398)
at org.specs2.control.eff.CollectedUnions.$anonfun$continuation$5(Unions.scala:90)
at org.specs2.control.eff.Arrs.go$1(Eff.scala:382)
at org.specs2.control.eff.Arrs.apply(Eff.scala:398)
at org.specs2.control.eff.Interpret$$anon$4.$anonfun$onEffect$4(Interpret.scala:243)
at scalaz.std.EitherInstances$$anon$13.bimap(Either.scala:54)
at scalaz.std.EitherInstances$$anon$13.bimap(Either.scala:51)
at scalaz.syntax.BifunctorOps.bimap(BifunctorSyntax.scala:9)
at org.specs2.control.eff.Interpret$$anon$4.onEffect(Interpret.scala:243)
at org.specs2.control.eff.Interpret$$anon$4.onApplicativeEffect(Interpret.scala:251)
at org.specs2.control.eff.Interpret$$anon$4.onApplicativeEffect(Interpret.scala:235)
at org.specs2.control.eff.Interpret.go$2(Interpret.scala:332)
at org.specs2.control.eff.Interpret.interceptLoop(Interpret.scala:339)
at org.specs2.control.eff.Interpret.interceptLoop$(Interpret.scala:274)
at org.specs2.control.eff.Interpret$.interceptLoop(Interpret.scala:636)
at org.specs2.control.eff.Interpret.intercept(Interpret.scala:261)
at org.specs2.control.eff.Interpret.intercept$(Interpret.scala:234)
at org.specs2.control.eff.Interpret$.intercept(Interpret.scala:636)
at org.specs2.control.eff.Interpret.intercept1(Interpret.scala:268)
at org.specs2.control.eff.Interpret.intercept1$(Interpret.scala:267)
at org.specs2.control.eff.Interpret$.intercept1(Interpret.scala:636)
at org.specs2.control.eff.ErrorInterpretation.catchError(ErrorEffect.scala:143)
at org.specs2.control.eff.ErrorInterpretation.catchError$(ErrorEffect.scala:126)
at org.specs2.control.eff.ErrorEffect$.catchError(ErrorEffect.scala:201)
at org.specs2.control.eff.ErrorInterpretation.whenFailed(ErrorEffect.scala:154)
at org.specs2.control.eff.ErrorInterpretation.whenFailed$(ErrorEffect.scala:153)
at org.specs2.control.eff.ErrorEffect$.whenFailed(ErrorEffect.scala:201)
at org.specs2.control.eff.ErrorInterpretation.orElse(ErrorEffect.scala:119)
at org.specs2.control.eff.ErrorInterpretation.orElse$(ErrorEffect.scala:118)
at org.specs2.control.eff.ErrorEffect$.orElse(ErrorEffect.scala:201)
at org.specs2.control.package$Operations$.orElse(package.scala:286)
at org.specs2.control.package$operationOps.orElse(package.scala:177)
at org.specs2.runner.SpecificationsFinder.$anonfun$findSpecifications$2(SpecificationsFinder.scala:36)
at scala.collection.immutable.List.map(List.scala:287)
at org.specs2.runner.SpecificationsFinder.$anonfun$findSpecifications$1(SpecificationsFinder.scala:34)
Can you please try 4.3.2
because @edmundnoble fixed a bunch of recursion issues: https://github.com/etorreborre/specs2/releases/tag/SPECS2-4.3.2
Just to let you know about the reason for the delay: migrating of our project to 4.x is rather cumbersome: When upgrading, everything compiles but Jenkins gets reproducibly red at a lot of places so I need get time approved to investigate into how this happens...
Ok, no worries, thanks for the update.
Trying with 4.3.2, I'm not experiencing unnecessary spec instantiations right now. Let me reopen the issue should I get it again.
Hi Eric, when using
SpecificationsFinder
some superfluous instantiations take place. Often this is transparent but sometimes it mutates to a serious issue. This is the case when writing specs based on AkkaTestKit
since I need to pass an actor system toTestKit
including some ports. Now, on the second instantiation, that port is bound so I inevitably get an exception. Was it possible for you to remove any repeated instantiation? Otherwise, what else would you suggest? Peter