Magnolia 4.5 reached end of life on June 30, 2016. This branch is no longer supported, see End-of-life policy.
Magnolia uses the Java filter concept, introduced in the Java Servlet specification version 2.3. A filter captures and processes a request before it reaches a servlet. Filters typically do not themselves create responses but provide universal functions that can be "attached" to any type of servlet or JSP page. See also the list of filters.
This diagram shows a typical request process in Magnolia.
In the diagram you can see the following filters:
MgnlContextwhich is local to the request and available on every further filter. The context provides a lot of useful functions.
The filter chain calls the
doFilter(request, response, chain) of the next filter. If the filter wants to continue the chain,
chain.doFilter(request, response) will be called.
A filter which can fullfill the request typically has a
There are other filters which just do some processing in the request handling.
If you look at the
web.xml of a Magnolia web application, you will see that it only defines one filter (
) and one listener (
The listener initializes Magnolia while the filter handles all requests.
The main filter
is a single filter which in turn executes a chain of other filters. The other filters are not configured in
web.xml but in Magnolia's
config workspace at
In the filter configuration you can again have single filters or filter chains. A filter chain consists of a list of single filters represented by child nodes. A filter node has a
class property which specifies the implementing class and can optionally have an
If the filter is enabled (default) then the filter will be executed, otherwise the filter will be bypassed. A filter or a filter chain can define rules to determine when a filter should be bypassed. The configuration of bypasses is done using voters.
This example shows that the URI for the login form is bypassed in the
Filters provide the ability to encapsulate recurring tasks and modularize code. They can also transform a response from a servlet or a JSP page. A common task is to format data sent back to the client, such as sending XML instead of HTML.
Some functions filters can perform:
Incoming requests to display a page are handled by the filter chain which is the place to start if you want to add your own business logic to Magnolia. A typical use case is to integrate a new framework with Magnolia. Integration of a new framework is generally accomplished by implementing the following steps:
Read the request and decide if the framework should handle it. Implement a filter to do this task and place the filter in the proper order in the filter chain. You can save the resulting model to be rendered as an attribute of the request's MgnlContext object as follows.
Access the model in your rendering system using JSTL like this.
These points are where Magnolia request handling can be extended with additional custom business logic:
Interface / Parent Class
The filters in the filter chain are executed in the configured order in the repository. Objects you store as attributes of the request's MgnlContext object can be used as JSTL variables later.
Define a renderer with a new type in a module's template-renderers section.
Use this new type in the template's
Define a renderer with a new type in a module's paragraphs-renderers section.
Use this new type in the component's