[undertow-dev] Predicate Handlers

[Andrig Miller]

----- Original Message -----
> From: "Anil Saldhana" <asaldhan at redhat.com>
> To: "Andrig Miller" <anmiller at redhat.com>
> Cc: undertow-dev at lists.jboss.org, "Stuart Douglas" <sdouglas at redhat.com>
> Sent: Monday, May 13, 2013 6:25:24 PM
> Subject: Re: [undertow-dev] Predicate Handlers
> 
> 
> 
> On May 13, 2013, at 6:55 PM, Andrig Miller <anmiller at redhat.com>
> wrote:
> 
> > 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
> 
> Ok - if you look at Stuart's original email, it does say Wildfly
> config file for specifying predicates. If you assume that to be in
> the domain model, the specification of the predicates via DRL, can
> be done in the domain model. I am just wondering if the use case is
> large enough to warrant a rules engine. If yes, then drools core
> will save time.
> 
> But from Stuart's response, use case is not large enough to require
> rules engine. I withdraw my suggestion. :)
> 
> 

Understood.

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
> >> 
>