[
https://issues.apache.org/jira/browse/LABS-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Simone Gianni resolved LABS-279.
--------------------------------
Resolution: Fixed
> [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: Current
>
>
> 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]
