[MGNLSCH-34] Two different contexts available to commands executed by CommandJob Created: 11/Jan/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Closed
Project: Scheduler
Component/s: None
Affects Version/s: 1.5.4
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Magnolia International Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MGNLSCH-35 Contexts available to commands execut... 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   

The Context instance passed to info.magnolia.commands.MgnlCommand#execute by info.magnolia.module.scheduler.CommandJob is not the same that's available on the thread local with MgnlContext.getInstance(). Is there any reason for that ? (can't see any myself)



 Comments   
Comment by Jan Haderka [ 27/Jan/13 ]

Yes, the difference is same when executing commands via workflow or even when invoking commands via http request - if normal (user) context is available, such context would be used, for workflow execution or scheduled commands there is no user context, so simple context with available parameters is passed instead. The only context available via MgnlContext.getInstance() is system context which imho should not be propagated to commands by default. If there is a need to ever execute commands in system context I would prefer to have separate job or at the very least configuration flag that would have to be set by user creating job explicitly to ensure they are aware of the danger.

Comment by Magnolia International [ 26/Feb/13 ]

... or code that explicitly acquires the system context. My point was, there are 2 ways of accessing a Context instance, and they're returning a different instance. If that's also the case in workflow, that doesn't make it less of an issue.

Generated at Mon Feb 12 10:45:15 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.