You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@deltaspike.apache.org by "John D. Ament" <jo...@apache.org> on 2015/10/10 02:24:12 UTC
Deactivation and redeployment
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
Re: Deactivation and redeployment
Posted by "John D. Ament" <jo...@apache.org>.
Ok, I've pushed up the change. Please take a look and let me know if you
have any comments.
On Sun, Oct 11, 2015 at 3:33 AM Christian Kaltepoth <ch...@kaltepoth.de>
wrote:
> +1 for disabling the cache if the project stage is not "production".
>
> 2015-10-10 23:46 GMT+02:00 John D. Ament <jo...@apache.org>:
>
> > 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 <
> > gerhard.petracek@gmail.com>
> > 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 <jo...@apache.org>:
> > >
> > > > 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 <
> > > > gerhard.petracek@gmail.com> 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 <jo...@apache.org>:
> > > > >
> > > > > > 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 <
> > johndament@apache.org>
> > > > > > 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
>
Re: Deactivation and redeployment
Posted by Christian Kaltepoth <ch...@kaltepoth.de>.
+1 for disabling the cache if the project stage is not "production".
2015-10-10 23:46 GMT+02:00 John D. Ament <jo...@apache.org>:
> 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 <
> gerhard.petracek@gmail.com>
> 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 <jo...@apache.org>:
> >
> > > 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 <
> > > gerhard.petracek@gmail.com> 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 <jo...@apache.org>:
> > > >
> > > > > 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 <
> johndament@apache.org>
> > > > > 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
Re: Deactivation and redeployment
Posted by "John D. Ament" <jo...@apache.org>.
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 <ge...@gmail.com>
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 <jo...@apache.org>:
>
> > 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 <
> > gerhard.petracek@gmail.com> 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 <jo...@apache.org>:
> > >
> > > > 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 <jo...@apache.org>
> > > > 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
> > > > >
> > > >
> > >
> >
>
Re: Deactivation and redeployment
Posted by Gerhard Petracek <ge...@gmail.com>.
+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 <jo...@apache.org>:
> 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 <
> gerhard.petracek@gmail.com> 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 <jo...@apache.org>:
> >
> > > 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 <jo...@apache.org>
> > > 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
> > > >
> > >
> >
>
Re: Deactivation and redeployment
Posted by "John D. Ament" <jo...@apache.org>.
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 <
gerhard.petracek@gmail.com> 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 <jo...@apache.org>:
>
> > 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 <jo...@apache.org>
> > 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
> > >
> >
>
Re: Deactivation and redeployment
Posted by Gerhard Petracek <ge...@gmail.com>.
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 <jo...@apache.org>:
> 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 <jo...@apache.org>
> 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
> >
>
Re: Deactivation and redeployment
Posted by "John D. Ament" <jo...@apache.org>.
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 <jo...@apache.org> 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
>