Web Action Entry v3.0

[adrw]

Currently...
two multibindings for each environment (dev, prod) to bind WebActionEntry to {WebProxyAction|StaticResourceAction} and {WebProxyEntry|StaticResourceEntry} to input parameter {upstream server url | resource path}

Development

multibind<WebActionEntry>().toInstance(WebActionEntry<WebProxyAction>("/_admin/"))
multibind<WebProxyEntry>().toInstance(WebProxyEntry("/_admin/", "http://localhost:3100/"))

Production

multibind<WebActionEntry>().toInstance(WebActionEntry<StaticResourceAction>("/_admin/"))
multibind<StaticResourceEntry>().toInstance(StaticResourceEntry("/_admin/", "classpath:/web/_admin/"))

Todo
Change this so only one Web Action Entry binding per environment. Construct the action in the WebActionEntry binding with the input parameters. Thus:

• simpler multibindings
• no more "Search for matching entry" in each action since each will be constructed with the exact matching binding
• enforce the current idiom that WebActionEntry and {WebProxyEntry|StaticResourceEntry} have the same path prefix

Potentially look something like this:

multibind<WebActionEntry>().toInstance(WebActionEntry("/_admin/", StaticResourceAction("classpath:/web/_tab/dashboard/")))

[adrw]

Todo
Have WebProxyAction fall back to StaticResourceAction so that all dev servers do not need to be running for all tabs when in development environment.

Considerations
Currently there is the assumption that a WebProxyAction and StaticResourceAction will never be bound simultaneously on the same prefix. Thus each using the same @Get() annotation prefix will not have any "double annotation with same prefix" issues.

Approach 1

• Ignore the suggested previous comment changes and continue to have WebProxyEntry and StaticResourceEntry bindings that are separate from the respective WebProxyAction and StaticResourceAction bindings
• Merge the two actions and have logic that, if in development, first checks for a match on WebProxyEntry, and if the forward request fails, passes the resource to the StaticResource code

Approach 2

• Proceed with the changes as outlined in previous comment
• Change the limitations on binding multiple request annotation classes to the same path and provide some sort of ordering and fall back mechanism such that WebProxyAction is bound at a higher priority than StaticResourceAction and if WebProxyAction fails, than the request is handed off to StaticResourceAction

[adrw]

Development Action that handles forwarding to Proxy, then Static if fails

DevelopmentAction(WebProxyAction(...parameters), StaticResourceAction(...parameters))