Also it would be incredibly slow and would be massive overkill for the
use cases we are talking about. 'Fast' has two different meanings when
you are talking about a rules engine and a web server.
Stuart
Andrig Miller 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
----- Original Message -----
> From: "Anil Saldhana"<asaldhan(a)redhat.com>
> To: "Stuart Douglas"<sdouglas(a)redhat.com>
> 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>
> 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
>