Am 01.11.19 um 14:24 schrieb Romain Manni-Bucau:
>
>
> Le ven. 1 nov. 2019 à 11:26, Felix Schumacher
> <felix.schumac...@internetallee.de
> <mailto:felix.schumac...@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.schumac...@internetallee.de
>>     <mailto:felix.schumac...@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 <ma...@apache.org
>>>         <mailto:ma...@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-unsubscr...@tomcat.apache.org
>>>             <mailto:dev-unsubscr...@tomcat.apache.org>
>>>             For additional commands, e-mail:
>>>             dev-h...@tomcat.apache.org
>>>             <mailto:dev-h...@tomcat.apache.org>
>>>

Reply via email to