Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Devstatus
Statusinprogressimplemented
Target5.3

In progress with See

Jira
serverMagnolia - Issue tracker
keyMAGNOLIA-5708
- some of the ideas below are being worked on, such that this page isn't exactly up to date.

Purpose

The Problem

Servlet mappings are currently configured under /filters/servlets. Often times, other components in the system need to know about those mappings. A simple example: generating links for the DAM servlet.

...

Such a mapping could be configured in the module's own class - and therefore used by the servlet mapping AND other arbitrary components (URI2RepoMapping, Link API, templating functions, ...)

 

Proposal

Concept

Introduce a subclass for ServletDispatchingFilter (which uses a specific impl of  info.magnolia.cms.filters.Mapping).an optional interface that servlets can implement. The interface exposes a method which servlets implement to return their "self" mapping.

Servlets can still be used with the current mechanism, aka "configured mappings", or with the new one : a developer would need to subclass that new Filter class replacement and implement a getDynamicMapping() method.({{SelfMappingServlet}}, or both.

This thus allows other components to use the same path, configured in one single place, for different purposes (typically to generate links)

(Where this method would delegate to MyModule.getFooPath(), and MyModule would be @injected in said filter.

No changes in configuration are necessary. The same filter is still used to wrap the servlet (info.magnolia.cms.filters.ServletDispatchingFilter). The new optional interface is info.magnolia.cms.filters.SelfMappingServlet.

Implementation example:

Code Block
languagejava
public class DamDownloadServlet extends publicHttpServlet staticimplements classSelfMappingServlet DamServletWrappingFilter{
extends ThatNewSubclassOfServletDFilter {  // ...
     private final DamCoreConfiguration damCfgconfiguration;


        @Inject
        public FilterDamDownloadServlet(DamCoreConfiguration configuration) {
            this.damCfgconfiguration = configuration;
        }


    @Override
  // This would be abstract in super class
        protected String getDynamicMappingpublic String getSelfMappingPath() {
            return damCfgconfiguration.getDownloadPath() + "/*";
        }
 

    @Override
  // Optionally, weprotected could do this; seems to make sense, would remove redundant config (this filter will always be coupled with this servlet, won't it)
        protected Class getServletClass() void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
            return DamDownloadServlet.class;
        }
    }

This thus allows other components to use the same path, configured in one single place, for different purposes (typically to generate links)

(Where this method would delegate to MyModule.getFooPath(), and MyModule would be @injected in said filter.

Implementation

Screenshots should be speaking enough:

Current servet mapping:

Image Removed

Proposal:

1) Path (mapping) in the module:

Image Removed

2) Different configuration for the servlet node:

Image Removed

Status

I have a POC working in my local DAM branch.

I would suggest having this (the abstract) in core.

I can update this concept with proposed naming.

Additionally, might make sense to change the package of these new classes (from info.magnolia.cms.filters to info.magnolia.servlets and/or info.magnolia.filters.servlets)

...

// ...

In the above example, DamCoreConfiguration is a module class which represents the DAM module's configuration (see screenshot below) and is simply injected in the servlet. If the configuration changes, the mapping changes is reflected.

Image Added