[MAGNOLIA-2893] Review commands to ensure they reset values of their private variables in release() method Created: 13/Oct/09  Updated: 23/Jan/13  Resolved: 13/Oct/09

Status: Closed
Project: Magnolia
Component/s: activation, admininterface, core, workflow
Affects Version/s: 4.1.1
Fix Version/s: 4.2

Type: Bug Priority: Major
Reporter: Jan Haderka Assignee: Jan Haderka
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MAGNOLIA-3880 Mapping of PathMappedFlowCommand is i... Closed
relation
is related to MAGNOLIA-1770 commands: create a single instance pe... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

Currently most of the commands do not release values of their private variables in the release() method. As the command instances are pooled for later reuse, they might be reused with values of some private variables set incorrectly. This leads to some random, hard to reproduce issues for example in activation.



 Comments   
Comment by Jan Haderka [ 13/Oct/09 ]

Done for:

  • ActivationCommand
  • BaseRepositoryCommand
  • BaseActivationCommand
  • MessageCommand
  • RuleBasedCommand
  • VersionCommand
  • ActivationFlowCommand
  • FlowCommand
  • PathMappedFlowCommand
  • TypeActivateCommand
  • TypeDeleteCommand
  • DataActivateAllCommand
  • DataDeactivateAllCommand
  • DataDeleteAllCommand
  • DeleteCommand
  • ImportCommand
  • DeactivationCommand
  • BaseDataAllCommand
Comment by Philipp Bärfuss [ 13/Oct/09 ]

This is somehow related to MAGNOLIA-1770. We should probably drop the pooling completely.

Generated at Mon Feb 12 03:41:09 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.