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 >

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

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

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 >

On May 13, 2013, at 6:55 PM, Andrig Miller&lt;anmiller(a)redhat.com&gt; 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. :) > ----- Original Message ----- >> From: "Anil Saldhana&quot;&lt;asaldhan(a)redhat.com&gt; >> To: "Stuart Douglas&quot;&lt;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&lt;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 >>

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

I like general idea but not the place where I configure it, at least based on sniplet below. <handlers> part of configuration is for defining handlers not for defining "flow" It would make more sense to have predicates defined on level of mapping handlers to certain flow then to have predicates defined on handler definition. Idea of configuration on top of my head: --------------- <server name="default-server" default-host="localhost" servlet-container="blah"> .... <host name="default-host" alias="localhost, some.host"> <location name="/" handler="welcome-content"> <filter-ref name="compression" enabled="maxContentSize(10000) and not responseHeaderContains[name=Content-Type, value='application/zip']"/> </location> </host> ... ... <filters> <compression name="compression"> <bzip enabled="pathMatch[*.js] or pathMatch[*.css]" /> <deflate> </compression> </filters> ----------------- But yet again that would work great for filters such as compression, but not so great for "content" handlers. This is based on what we currently have in undertow subsystem, only thing we would need to add is the predicate support. For "content" handlers I think your proposal of configuration would be the only feasible one. -- tomaz > -----Original Message----- > From: undertow-dev-bounces(a)lists.jboss.org [mailto:undertow-dev- > bounces(a)lists.jboss.org] On Behalf Of Stuart Douglas > Sent: Monday, May 13, 2013 5:37 PM > To: Anil Saldhana > Cc: undertow-dev(a)lists.jboss.org > Subject: Re: [undertow-dev] Predicate Handlers > > This would not be a specific config file, but rather just a line in > standalone.xml: > > <handlers> > <compression enabled="maxContentSize(10000) and not > responseHeaderContains[name=Content-Type, value='application/zip']"> > <bzip enabled="pathMatch[*.js] or pathMatch[*.css]" /> > <deflate> > </compression> > </handlers> > > Stuart > > Anil Saldhana wrote: >> On May 13, 2013, at 6:55 PM, Andrig Miller&lt;anmiller(a)redhat.com&gt; 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. :) >> >> >>> ----- Original Message ----- >>>> From: "Anil Saldhana&quot;&lt;asaldhan(a)redhat.com&gt; >>>> To: "Stuart Douglas&quot;&lt;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&lt;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/predicate >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> > _______________________________________________ > undertow-dev mailing list > undertow-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/undertow-dev