+1 for disabling the cache if the project stage is not "production".
2015-10-10 23:46 GMT+02:00 John D. Ament <[email protected]>: > Glad we agree ;-) > > https://issues.apache.org/jira/browse/DELTASPIKE-1001 > > If no one raises any objections by tomorrow evening eastern I'll push up > the change and update the docs. > > John > > On Sat, Oct 10, 2015 at 5:33 PM Gerhard Petracek < > [email protected]> > wrote: > > > +1 to skip caching in case of ProjectStage.UnitTest (and > > maybe ProjectStage.Development) > > > > regards, > > gerhard > > > > > > > > 2015-10-10 23:22 GMT+02:00 John D. Ament <[email protected]>: > > > > > Gerhard, > > > > > > I think it has more to do with making sure the test is doing the bare > > > minimum possible. > > > > > > Another way to think about it is to specify on start up that > > > ClassDeactivation shouldn't cache, rather than exposing a "reset" > > function > > > in the code base. Like maybe if project stage == Development, don't > even > > > cache. > > > > > > Feasible? Sensible? Agreeable? > > > > > > On Sat, Oct 10, 2015 at 12:22 PM Gerhard Petracek < > > > [email protected]> wrote: > > > > > > > hi john, > > > > > > > > please provide a bit more information about the concrete use-case > (and > > > why > > > > you need different configurations for the same application). > > > > > > > > regards, > > > > gerhard > > > > > > > > > > > > > > > > 2015-10-10 2:28 GMT+02:00 John D. Ament <[email protected]>: > > > > > > > > > Sorry, linked to the wrong line > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/ClassDeactivationUtils.java#L54 > > > > > > > > > > John > > > > > > > > > > On Fri, Oct 9, 2015 at 8:24 PM John D. Ament < > [email protected]> > > > > > wrote: > > > > > > > > > > > Hey, > > > > > > > > > > > > I ran into a weird issue today. I have two tests based on > > > Arquillian, > > > > > and > > > > > > both have some DeltaSpike dependencies in them. > > > > > > > > > > > > The test I'm running is against Weld EE embedded, it's not > spawning > > > new > > > > > > JVMs or anything, but each test has its own deployment. The > weird > > > part > > > > > > about the two deployments is that they had different class > > > > > deactivators. I > > > > > > ran into an issue in that TestA ran before TestB. During TestB's > > > > > > execution, I was seeing deacitvation behavior based on the > > > > configuration > > > > > of > > > > > > TestA. > > > > > > > > > > > > I realized much later that the cause is that the class > deactivation > > > > > result > > > > > > is computed and cached, which is fine for production code but for > > > unit > > > > > > tests I would hope that it behaves more idempotent. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://github.com/apache/deltaspike/blob/master/deltaspike/core/api/src/main/java/org/apache/deltaspike/core/util/ClassDeactivationUtils.java#L47 > > > > > > > > > > > > I'm wondering if it's possible to expose a method to allow devs > to > > > > reset > > > > > > the deacitvation cache between test runs. > > > > > > > > > > > > WDYT? > > > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > -- Christian Kaltepoth Blog: http://blog.kaltepoth.de/ Twitter: http://twitter.com/chkal GitHub: https://github.com/chkal
