[undertow-dev] Predicate Handlers

[Andrig Miller]

>From the Andiamo perspective, I would not want to see an external DRL config file.  That violates one of our very first Andiamo tenants.

Andy

----- Original Message -----
> From: "Anil Saldhana" <asaldhan at redhat.com>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Monday, May 13, 2013 5:28:03 PM
> Subject: Re: [undertow-dev] Predicate Handlers
> 
> You definitely need the predicates. Thinking along First Order logic,
> I am wondering if this is just an use case for rules definition and
> processing - something drools has been doing for years.
> 
> Maybe all you need is Drools core lite (or whatever you want to call
> the core rules processing framework) and one DRL external config
> file.
> 
> On May 13, 2013, at 5:41 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> 
> > I think you may have missed the point.
> > 
> > Undertow uses handers, which are conceptually similar to valves,
> > and you
> > can still provide a custom handler to run any custom code you want.
> > 
> > The idea of predicates is that often you will only want a handler
> > to be
> > applied in a certain situation. So with the case of the compression
> > handler there may a number of things that may determine if a
> > request is
> > compressible or not, including:
> > - content-type
> > - size
> > - request path
> > - cache control headers etc
> > - accept-encoding (although this has to be handled by the
> > compression
> > handler to make sure the correct encoding is selected)
> > 
> > Without something like predicates we have to figure out what all
> > these
> > criteria are and code them into our handler, and then provide so
> > means
> > of configuring them. With predicates the compression handler just
> > worries about compression, and the predicate handler deal with if
> > the
> > request is compressible or not.
> > 
> > Also it is possible to provide custom predicates, so with this
> > approach
> > you can use custom code to decide if an existing handler should be
> > run
> > without having to modify or extend the handler.
> > 
> > Stuart
> > 
> > 
> > Bill Burke wrote:
> >> 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/predicate
> >>> 
> >>> 
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>