search

etorreborre / specs2

Software Specifications for Scala
http://specs2.org
Other
734 stars 215 forks source link

SpecificationsFinder instantiates Specs twice #592

Closed peter-empen closed 6 years ago

peter-empen commented 7 years ago

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 Akka TestKit since I need to pass an actor system to TestKit 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

etorreborre commented 7 years ago

Is it the case with 3.9.x and 4.0.0.x? Which version are you using please?

etorreborre commented 7 years ago

This is probably in both and a bug...

peter-empen commented 7 years ago

This is the case with 3.8.9 and before.

etorreborre commented 7 years ago

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.

peter-empen commented 7 years ago

How did you try to reproduce it?

etorreborre commented 7 years ago

A println in the SpecificationFinderSpec and run example n.4

peter-empen commented 7 years ago

Thank you. Please bear with me for further investigations.

etorreborre commented 7 years ago

Any news for this?

peter-empen commented 7 years ago

Sorry, it'll take another 10 days until I manage to get down to this.

peter-empen commented 6 years ago

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?

etorreborre commented 6 years ago

This could be the reason yes. Maybe you can fire up your code in a debugger, step through and see what's going on?

peter-empen commented 6 years ago

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.

etorreborre commented 6 years ago

Ok, thanks.

peter-empen commented 6 years ago

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)
etorreborre commented 6 years ago

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

peter-empen commented 6 years ago

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...

etorreborre commented 6 years ago

Ok, no worries, thanks for the update.

peter-empen commented 6 years ago

Trying with 4.3.2, I'm not experiencing unnecessary spec instantiations right now. Let me reopen the issue should I get it again.