[MAGNOLIA-1614] Refactor magnolia Context class hierarchy Created: 02/Jul/07  Updated: 23/Jan/13  Resolved: 06/Nov/07

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 3.1 M1
Fix Version/s: 3.5

Type: Task Priority: Major
Reporter: Sameer Charles Assignee: Philipp Bärfuss
Resolution: Fixed Votes: 0
Labels: None
Σ Remaining Estimate: Not Specified Remaining Estimate: Not Specified
Σ Time Spent: Not Specified Time Spent: Not Specified
Σ Original Estimate: Not Specified Original Estimate: Not Specified

Attachments: PNG File context-refactoring.png     PNG File strategies-in-context.png     PNG File webcontext-creation.png    
Issue Links:
relation
is related to MAGNOLIA-1758 WebcontextImpl stores a non-serializa... Closed
is related to DOCU-47 Improve the dev. docs on magnolia arc... Closed
Sub-Tasks:
Key
Summary
Type
Status
Assignee
MAGNOLIA-1798 don't store HierarchyManager, AccessM... Sub-task Closed Philipp Bärfuss  
MAGNOLIA-1799 unset context in all threads, add Mgn... Sub-task Closed Philipp Bärfuss  
MAGNOLIA-1800 SystemContext should not share the jc... Sub-task Closed Philipp Bärfuss  
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Date of First Response:

 Description   

To avoid issues like MAGNOLIA-1598 & MAGNOLIA-1605 and to make abstract context more usable we should
allow plugin Strategies like "repository access strategy", "attribute strategy"

there can be various patterns we can use here, I will post more when we start work on it.



 Comments   
Comment by Sameer Charles [ 27/Jul/07 ]

To start with I will add login/logout to context this will give us much better control to use these contexts in
environments like workflow or activation where you need to impersonate based on the workflow definition as defined in MAGNOLIA-1644

Comment by Sameer Charles [ 30/Jul/07 ]

needs much more work than anticipated

Comment by Philipp Bracher [ 31/Jul/07 ]

The system context should not use ContentRepository to get hierarchy manager instances. It should keep its own instances. In fact ContentRepository should not keep any instances at all. This allows to reinitialize the system context.

Comment by Philipp Bracher [ 25/Oct/07 ]

I attached a diagram explaining the changes we do:

  • UserContext interface providing login logout
  • consequent usage of release
  • RepositoryAcquringStrategy (responsible for getting HierarchyManager, AccessManager, QueryManager)
  • AttributeStrategy (responsible for storing attributes: map, request, session, ....)
  • WebContext and Anonymous context are not two different classes/instances anymore
Comment by Philipp Bracher [ 25/Oct/07 ]

Attached a diagram showing how the strategies could look like.

Broaching the usage of a ContextFactory

Comment by Philipp Bracher [ 25/Oct/07 ]

Attached a sequence diagram which should illustrate the roles of ContextFilter, LoginFilter, LogoutFilter and the context methods login(), logout() and release()

Comment by Philipp Bracher [ 25/Oct/07 ]

sorry for not rotating the images before uploading

Comment by Philipp Bracher [ 26/Oct/07 ]

All the existing interfaces (Context, WebContext) and MgnlContext should not change at all.

Comment by ashapochka [ 29/Oct/07 ]

Context Refactoring

Comment by ashapochka [ 29/Oct/07 ]

Strategies in Context

Comment by ashapochka [ 29/Oct/07 ]

WebContext Creation

Comment by ashapochka [ 06/Nov/07 ]

The strategies are created, AnonymousContext is not used in ContextFilter anymore. A single web context is created and then can be logged in / logged out. More testing concerning the correct set up of permissions and jcr for an anonymous is needed.

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