tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: RewriteMap parsing
Date Fri, 01 Nov 2019 20:04:50 GMT
Hi Felix

Overall it looks good but I'd do two minor changes:

1. Only lookup providers once per context (ServiceLoader result being
cached per parser instance)
2. Likely lazy load the parsing after context startup to ensure ioc can be
used (spring web or cdi lookups)

Hope it makes sense

Le ven. 1 nov. 2019 à 18:31, Felix Schumacher <
felix.schumacher@internetallee.de> a écrit :

>
> Am 01.11.19 um 14:24 schrieb Romain Manni-Bucau:
>
>
>
> Le ven. 1 nov. 2019 à 11:26, Felix Schumacher <
> felix.schumacher@internetallee.de> a écrit :
>
>>
>> Am 01.11.19 um 11:11 schrieb Romain Manni-Bucau:
>>
>> Through the spi IMHO and if it can be ambiguous use an ordinal or
>> priority to let it be overriden maybe?
>>
>> Do we want users to be able to overwrite our functions? Is the "int:"
>> namespace free for everyone?
>>
> I think so, like enabling to enrich it (often implemented as a delegation)
>
>
>
> Should we break the context startup in case of duplicate functions in the
>> registry?
>>
>
> If they have the same priority I think so.
>
>
> I have submitted a PR that tries to implement the discussed features:
> https://github.com/apache/tomcat/pull/221
>
> Felix
>
>
>
> Felix
>>
>>
>> Le ven. 1 nov. 2019 à 10:46, Felix Schumacher <
>> felix.schumacher@internetallee.de> a écrit :
>>
>>>
>>> Am 28.10.19 um 23:06 schrieb Romain Manni-Bucau:
>>>
>>> +1 for quotes
>>>
>>> Can the "function" support be pluggable either with an explicit registry
>>> or a SPI? Would be awesome to enrich it in "super tomcat" instances
>>> (thinking to meecrowave, tomee and maybe spring boot).
>>>
>>> The function support is already pluggable (by the configuration file :),
>>> but I thought about adding SPI.
>>>
>>> It is unclear to me, how to determine the namespace ("int:" in the httpd
>>> example), should it be given by the Service Provider? Would "int" be
>>> reserved for our own functions? How could we achieve such a reservation
>>> mechnism?
>>>
>>> Felix
>>>
>>>
>>> Le lun. 28 oct. 2019 à 21:43, Mark Thomas <markt@apache.org> a écrit
:
>>>
>>>>
>>>>
>>>> On 27/10/2019 11:27, Felix Schumacher wrote:
>>>> > Hi all,
>>>> >
>>>> > while looking at the RewriteMap configuration, I noticed, that parsing
>>>> > of the RewriteMap directive is a bit minimal. Parameters are split at
>>>> > whitespace (no quotes will be recognized) and only the first of the
>>>> > optional parameters will be used.
>>>> >
>>>> > Should this be changed? If so, should we introduce quoting
>>>> capabilities
>>>> > to gather the "one" optional parameter, or allow multiple parameters?
>>>> >
>>>> > Version "quote":
>>>> >
>>>> > RewriteMap m1 example.MyMap "some params"
>>>> >
>>>> > Version "multiple"
>>>> >
>>>> > RewriteMap m2 example.OtherMap one two three
>>>> >
>>>> > Or should it be a combination?
>>>>
>>>> That is probably the most flexible option. I'd lean towards this option
>>>> but would be happy to support the majority view if different.
>>>>
>>>> > "quote" would be sort of compatible with the current interface, as we
>>>> > still have only one parameter. "multiple" would be a nicer interface
>>>> for
>>>> > the implementer of the map.
>>>> >
>>>> > Another thing I noticed, is that the httpd rewrite map feature has a
>>>> few
>>>> > builtin maps, that could be useful to supply with our implementation.
>>>> > Any thoughts on supplying those? (I thought about the maps
>>>> > int:[toupper,tolower,escape,unescape], txt:, rnd: and possibly a new
>>>> one
>>>> > called jdbc:{jndi-connection}:{sql statement with placeholder}. For
>>>> > these elements a quote detection would be a must)
>>>>
>>>> I don't recall any requests for these on the users list but maybe that
>>>> is because the feature isn't that well known.
>>>>
>>>> Mark
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>

Mime
View raw message