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

What do you think, should we merge it? Are there rules to be respected, do 
we need a vote taking place? What's Jeffery's opinion?

-Georg



Von:    "Georg Kallidis" <[email protected]>
An:     "Turbine Developers List" <[email protected]>
Datum:  15.01.2021 12:45
Betreff:        Re: Re: Need some help: was: svn commit: r1885148 - 
/turbine/core/branches/URLMapperService/



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

I fixed it by adjusting property max-total for fulcrum pool2 in fulcrum 
parser component (by default 1024, which was the threshold) in 
fulcrumcomponentConfiguration.xml.



Von:    Thomas Vandahl <[email protected]>
An:     Turbine Developers List <[email protected]>
Datum:  15.01.2021 09:49
Betreff:        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


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]