Pseudo restore PathMappings.getMatch(String) for backwards compat reasons

[mark-christiaens]

Jetty version(s)
10.0.10

Java version/vendor

Not relevant

OS type/version

Not relevant

Description

Commit 8de55150fe1889c2c748b821a4f76bce9cbf8f9a deprecated PathMappings#getMatch(String) and made it throw an UnsupportedOperationException.

    /** 
     * @deprecated use {@link #getMatched(String)} instead
     */
    @Deprecated
    public MappedResource<E> getMatch(String path)
    {   
        throw new UnsupportedOperationException("Use .getMatched(String) instead");                                                                                   
    }   

This is a non-backwards compatible change. Our code now throws exceptions. I suspect this should not be done in a minor release.

How to reproduce?

Not relevant

[joakime]

A bit surprised someone is using PathMapping directly like this.
It's not really exposed to outside use directly like that.
Typical usage is to just give either the ServletHolder/ServletHandler or WebSocketServer tree a PathSpec and the underlying implementation uses the PathMappings object to manage them.
How are you using it?

Anyway, the .getMatch(String path) was set to UnsupportedOperationException in commit 8de5515
I don't recall why.
I'll post a PR to restore this, simply by calling .getMatched(String) internally.

[joakime]

Ah, yes.

The API is designed now to return MatchedResource which returns the pathSpec, Resource, pathMap, and pathInfo on the hit.
The old MappedResource is still there, as the input to establish the mapping, but not returned in any .getMatch*() API.

The MappedResource doesn't have the pathMap and pathInfo bits.
The new MatchedResource does, and is an object used with in the dispatch in Servlet and WebSocket Server.
This skips another lookup/match for the Servlet Name, Servlet Path, and Path Info portions of the various specs.

A pseudo backward compatible fix is to have the old .getMatch(String) return a new MappedResource every time it is called, and skipping the information from MatchedResource.

A quick workaround would be ...

public class OldPathMappings<E> extends PathMappings<E>
{
    @Override
    public MappedResource<E> getMatch(String path)
    {
        MatchedResource<E> matchedPath = getMatched(path);
        return new MappedResource<>(matchedPath.getPathSpec(), matchedPath.getResource());
    }
}

This API .getMatch(String) is flagged as deprecated and is flagged for deletion. (in fact it's already been deleted in Jetty 12)

[joakime]

A pseudo backward compat option has been opened as PR #8629

[margus2]

This issue affects Jetty 9.4.49 too.

[joakime]

@margus2 Jetty 9.4.x is at End of Community support.

• EoCS (End of Community Support) for Jetty 9 - June 2022 #7958