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]
smime.p7s
Description: S/MIME Cryptographic Signature
