Re: [undertow-dev] Predicate Handlers

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(a)redhat.com&gt; > To: "Stuart Douglas" <sdouglas(a)redhat.com&gt; > Cc: undertow-dev(a)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(a)redhat.com&gt; > 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-dev mailing list >>>> undertow-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >> _______________________________________________ >> undertow-dev mailing list >> undertow-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/undertow-dev > > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev >