{"id":4897,"date":"2012-05-31T10:04:15","date_gmt":"2012-05-31T08:04:15","guid":{"rendered":"http:\/\/blog.orange11.nl\/?p=4897"},"modified":"2012-05-31T10:04:15","modified_gmt":"2012-05-31T08:04:15","slug":"spring-context-configuration-in-magnolia","status":"publish","type":"post","link":"https:\/\/trifork.nl\/blog\/spring-context-configuration-in-magnolia\/","title":{"rendered":"Spring context configuration in Magnolia"},"content":{"rendered":"

Here at Trifork we have quite a Magnolia portfolio. We do not only install, configure and host the\u00a0actual CMS itself alone, we also design and implement pixel-perfect designs, and last but certainly not\u00a0least: integrate new or existing business processes from external resources.<\/p>\n

When we create any piece of software for such an integration, that software is 90% of the time a Spring\u00a0configured application. For example, when \u00a0we need to load content from an external database into the\u00a0Data module<\/a>, or when we want to create a Blossom dialog<\/a> that renders a select box based on results\u00a0from an external web service. We create these services in a separate abstraction layer, like most of us\u00a0would, so that we end up with a nice separate, reusable and testable module. The services we create are\u00a0usually configured in a number of Spring contexts.<\/p>\n

Loading your contexts in the Magnolia admin central.<\/h3>\n

Are you building your own Magnolia modules instead of Magnolia (1)? Are you letting your modules\u00a0configure your Magnolia instance (2)?
\nIf the answer to both of these questions is yes, and you do a\u00a0fair bit of Spring in your modules, you might want to read on!<\/p>\n

(1) Gr\u00e9gory Josephs’: Don\u2019t build Magnolia: build your projects.<\/a>
\n(2)\u00a0Gr\u00e9gory Josephs’: Don\u2019t configure Magnolia: let your projects configure it.<\/a><\/p>\n

<\/p>\n

How would we usually configure such a module<\/h2>\n

When you want to enable any kind of Spring in your Magnolia web application, you will probably add Springs’ ContextLoaderListener<\/em> in your web.xml<\/em> and either load all of the contexts directly using the\u00a0contextConfigLocation<\/em> parameter, or perhaps import ’em all in your root application context.<\/p>\n

Your regular contextConfigLocation<\/em> looks like the web.xml<\/em> excerpt below. There is nothing new going on here. Just plain old stuff.<\/p>\n

\n\t...\n\t<context-param>\n\t\t<param-name>contextConfigLocation<\/param-name>\n\t\t<param-value>\/WEB-INF\/applicationContext.xml<\/param-value>\n\t<\/context-param>\n\t<listener>\n\t\t<listener-class>org.springframework.web.context.ContextLoaderListener<\/listener-class>\n\t<\/listener>\n\t<filter>\n\t\t<display-name>Magnolia global filters<\/display-name>\n\t\t<filter-name>magnoliaFilterChain<\/filter-name>\n\t\t<filter-class>info.magnolia.cms.filters.MgnlMainFilter<\/filter-class>\n\t<\/filter>\n\t...\n\t<listener>\n\t\t<listener-class>info.magnolia.cms.servlets.MgnlServletContextListener<\/listener-class>\n\t<\/listener>\n\t...\n<\/pre>\n
What is the issue here, you might think? Well, nothing to be quite honest. This works like a charm, and when the ContextLoaderListener<\/em> is placed above the MgnlServletContextListener<\/em>, your services will even be able to access the Magnolia repositories. But when you are creating multiple modules that are reusable in multiple applications, that have multiple contexts, module dependencies etcetera, setting up and maintaining these configurations can become quite a hassle.<\/p>\n
In my opinion: when you want to add a module to Magnolia, whatever framework is used, the fact that you will possibly have to update the web.xml, modify any existing contexts to make it work is pretty annoying.\u00a0This approach also does not fit in Greg’s \u201cDon\u2019t configure Magnolia: let your projects configure it.\u201d principal. It should just work out of the box!<\/p>\n
Ah, Spring in Magnolia you’re saying? You mean Blossom!!<\/h2>\n
This is something that often Springs<\/em> to mind when discussing Magnolia in combination with Spring (no pun intended). Blossom<\/em><\/a> is a great way of using dynamically generated Dialogs<\/em><\/a> and their content validators, VirtualURIMappers<\/em><\/a> or Spring MVC controllers<\/em><\/a> in Magnolia (and much more). But the issue that I want to touch upon is purely the configuration of your Spring contexts in your module.<\/p>\n
Usually there is already a ContextLoaderListener<\/em> and root context present in your app. But when we actually want to enable a module like say Blossom<\/em><\/a> in our existing web application, you guessed it…, you will perhaps have to edit your web.xml again and add some more contexts to your existing application.
\nFor each and every module with an own configuration you’d have to repeat these steps.<\/p>\n
So when I am talking about Spring context loading in Magnolia, I really just mean the context loading itself. Either for using Blossom, or some of our own many modules, the integration of the actual context loading and managing the configuration is not very subtle or centralized.<\/p>\n
So then what would the ideal scenario look like?<\/h2>\n
Magnolia already has a very neat way of installing, updating and configuring modules. You can register dependencies in the config, or perhaps deltas in your version handler, and perform elaborate update tasks.
\nWhy not make use of all of these great features and actually take control of Magnolia’s rich dynamic configuration mechanism. It would be very fancy if one could just create a configuration node in a module, specifying any contexts that need to be loaded. Let the Magnolia ObservedManager<\/a><\/em> pick up any values that I set in the config for handling changes runtime. We could also export these configuration nodes, and bootstrap them upon version change. This way the configuration of a module is completely defined in the admincentral.<\/p>\n
We at Trifork are using Maven a lot in our projects. With modules like this we would just have to add a dependency to the application, and that’s it! The contexts are automatically added to the root context.<\/p>\n
This is exactly what we did a couple of years ago with our Magnolia\u00a0Spring context configuration module<\/strong><\/em>. Simple is beautiful, as appears in just about every Magnolia adminCentral you open.<\/p>\n
Set up instructions<\/h2>\n
The Magnolia\u00a0Spring context configuration module<\/strong><\/em>\u00a0is a maven module that you will have to add to your website’s pom.xml.\u00a0From that moment on, all your context configurations will be managed inside the Magnolia admin central and not in your webapp structure.<\/p>\n
Within the config node of your module, we can specify the spring-contexts and the spring-beans (override-able properties) that this module needs. In the example below, two contexts are loaded: the ‘spring-ws-context’ and an ‘external-db-context’. The contexts are expanded to show you the configuration needed for a context.<\/p>\n
\"\"<\/a><\/p>\n