IMO, you'd be better off providing a Valve architecture instead of
maintaining an expression language. I think you'll often hit a scenario
where the expression language isn't adequate enough and a user will need
to write code anyways. Plus a config-file expression language can't be
compiler checked.
On 5/12/2013 8:17 PM, Stuart Douglas wrote:
A fairly common requirement for web requests is to enable or disable
a
certain action based on the state of the request. e.g:
- disable compression if the response > 10Mb
- If the user agent is X add header Y
- If the path starts with /private disable caching
etc
To enable us to acomplish this Undertow has the concept of
predicates[1], which as you would expect are a function object that
takes the exchange as an argument and returns a boolean value.
We also provide boolean operator predicates (and, or, not) that allow
you to combine these predicates into arbitrarily complex values. The
idea is that if a user want to configure a conditional action on the
request they will use these predicates to specify the condition.
To that end we need some way of representing them in the Wildfly
configuration file, and so I have hacked up a basic syntax to configure
them, and I would like some feedback. The configuration syntax will
written directly into the standalone.xm and jboss-web.xmll to
conditionally enable handlers.
A basic example looks like:
path["/MyPath"] or (method[value="POST"] and not
requestHeadersPresent[value={Content-Type, "Content-Encoding"},
ignoreTrailer=true] )
The following boolean operators are built in, listed in order or
precedence:
- not
- and
- or
They work pretty much as you would expect them to. All other tokens are
taken
to be predicate names. If the predicate does not require any parameters
then the
brackets can be omitted, otherwise they are mandatory.
If a predicate is only being passed a single parameter then the
parameter name can be omitted.
Strings can be enclosed in optional quotations marks, and quotation
marks can be escaped using \"
Array types are represented via a comma separated list of values
enclosed in curly braces.
Predicate definitions themselves are loaded via a service loader
mechanim, with the service implementation specifying the name and the
parameter types.
I would be interested to hear what people think. At the moment this is
very simple, however a by product of this simplicity is that you need
multiple predicates to handle similar things (e.g.
requestHeadersPresent, responseHeadersPresent, requestHeaderContains,
requestHeaderEquals etc).
[1]
https://github.com/undertow-io/undertow/tree/master/core/src/main/java/io...
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev