Re: Need some help: was: svn commit: r1885148 - /turbine/core/branches/URLMapperService/

Hi Georg,

On 13.01.21 17:40, Georg Kallidis wrote:
> - override parameters is only applied when mapping from URL, but not the
> other way around. This might be as expected, as "simpleurling" reads from
> the provided parameters and if implicit parameter are set might not allow
> to override a value, as this is the defined matcher. As a result override
> parameter is asymmetric and not applied when creating the url (mapToURL),
> but only when "reading" from it (mapFromURL). Ignore parameters take
> precedence over all others.

Yes, this is intentional. Overriding parameters is supposed to be used 
when parameters are delivered that do not fit into the application 
(anymore). The use-case is deprecation of an URL parameter that was 
published before, for example.

> - Ignore-parameters in class URLMapentry is a Map, although only the keys
> are used, might be better an array, but for sake of simplicity having to
> care for only one XmlAdapter, this is not necessarily required.

This is not necessarily the case. You may want to ignore a certain 
key-value pair only, for example.

> - This works still in Java 16, but we should be aware of this:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.turbine.services.urlmapper.TurbineURLMapperService to method
> java.util.regex.Pattern.namedGroups()
> WARNING: Please consider reporting this to the maintainers of
> org.apache.turbine.services.urlmapper.TurbineURLMapperService
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release

Yes. I'll need to think about this again. Too bad that the method 
exists, but is private.

> The performance penalty when including it into the pipeline and in the
> velocity templates as application tool seems to be tolerable (but my
> performance test does not succeed with more than 1000 calls and I could
> not find the reason behind yet though ..).

I stumbled across this before. The may be something wrong with the pool 
handling of parsers. In my case, I got pool depletion with only local 
testing. Very strange.

Bye, Thomas