Undocumented changes to the task module instantiation behavior can break third-party add-ons

Issue Summary

Before Bamboo 8.2.1, every task execution implied a fresh instantiation of the task’s implementing class, i.e. one (separate) object per execution. With 8.2.1, this flipped to reuse of already instantiated task objects across different executions, i.e. the task classes are suddenly treated as singletons. If add-on's task implementation relies on some execution state being tracked on the object level, this change results in parallel executions overwriting each other’s state data.

The change consists of explicitly setting the isMutable() flag to false across multiple com.atlassian.bamboo.plugin.descriptor.* classes.

Steps to Reproduce

1. Install Bamboo to 8.2+
2. Install Tasks for AWS (Bamboo) by Utoolity add-on (as an example)
3. Create a plan 2 separate Jobs, both running the AWS CloudFormation Stacks task
4. Configure both plans to be run on local agents, at the same time
5. At the AWS CloudFormation Stacks task configuration, set the variables Namespace to custom.job1 and custom.job2 respectively.

Expected Results

The variable Namespaces defined will be respected inside the task context.

Actual Results

Bamboo either uses custom.job2 for both job1 and job2, or the defined namespace is ignored, and Bamboo uses the default "custom.aws" prefix for both jobs.

Workaround

1. Install the patch attached to the ticket by replacing file

   atlassian-bamboo/WEB-INF/lib/atlassian-bamboo-core-8.2.1.jar
   

   with the jar file attached to this ticket and restarting Bamboo server. atlassian-bamboo-core-8.2.1-bam-21728.jar

2. Use remote agents, if possible.