[refactoring][all] Running context to gather informations during cycle execution
--------------------------------------------------------------------------------
Key: LABS-279
URL: https://issues.apache.org/jira/browse/LABS-279
Project: Labs
Issue Type: New Feature
Components: Magma
Affects Versions: Current
Reporter: Simone Gianni
Assignee: Simone Gianni
Fix For: Next
Currently Magma executes an application, and this application has some cycles.
In a web application a "cycle" is a web request, in other kind of applications
(when there will be) cycles could be determined depending on the platform (in a
swing application a cycle is the execution of an event) or by programmatic
boundaries. Generally, a cycle is a stacktrace and is limited to one thread,
but that could be not-mandatory.
During this cycle, a number of informations are gathered that need to be made
available to various components. For example, every web handler needs to know
its relative url to properly resolve URLs, while every i18n string needs to
know the current context to properly determine the right translation.
In the future, a number of other components will require this informations. For
example the settings system could provide a way to customize some settings
depending on the context in a similar way as i18n does, or the various
factories (Database etc..) could be instructed to return different
implementations based on different contexts.
There are currently different systems that gather different informations in
parallel with cycle execution. These are the i18n contextualizer
(LocalizationContext), the web handler setup, the producer setup, and a few
others that operate on small areas.
They all succeed in what they are designed to do, but often fail to be
expandible enought. For example, bug LABS-257 is caused by the fact that the
current system for producers setup does not offer a way to retrieve current
context informations outside the tiny scoe it was designed for. This same
problem is also blocking LABS-278 and causing clutter here and there in the
code when URLRewritingStream is used. Similar limitations are also present in
the i18n LocalizationContext system, causing for example bug LABS-236.
The new system should be able to contain all the informations in parallel, and
be able to be augmented (thru AOP composition) with new features required by
different packages (for example, extrapolating the current url for web
components).
It could seem that having a parallel stack could create a performance problem,
or that it could be considered overkill because AOP already offer nice ways of
operating on the current, JVM, stacktrace (cflows, argument extraction etc..).
This AOP approach consideration is quite a good one, but has it's own
drawbacks. Since a number of context-related informations are used for dynamic
matching (both URLs and I18N are the case), they both need to construct
parallel stacks and cannot rely on plain AOP interception (if not to build
those stacks and keep them up to date). In fact, AOP is perfect when a
relatively "static" execution flow has to be tracked, but when things get
dynamic (there could be any number of handlers nesting in other handlers, any
number of i18n segments to evaluate) they can only build a specific stack.
When it comes to performance, we already have a system building four different
stacks (i18n segments, handlers stack, do-methods name stack and arguments
stack) just to provide current two functionalities, plus a fifth aspect for
specific WebHandlers setup. This already sounds like and aspect that should be
generalized by itself. Unifying it would reduce the number of calls and object
creation adding a single object instead of different objects to a single stack.
Different aspects would provide feed and update to this centralized entity, not
breaking the AOP principle of it being a cross cutting concert and organizing
the thing module by module (as it alreay happens for the i18n
LocalizationContext).
Also, the web part are acting in an IOC way. While this is great as a design,
when it comes to performance it is relatively easy to use it poorly and obtain
sub-optimal results. For example, every WebHandler receives its computed
relative URL, even if it is not going to use it, and the same happens for a
number of other properties which are defined in the base class and injected.
The centralized running context will be designed to be polled to obtain context
informations. Then eventually packages could poll it everytime to do injection
if it is really needed.
Another reason why a centralized solution is preferable is that it could be
optimized easier than working on every different context mechanism that
could/will appear in different packages.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
