On Fri, Mar 27, 2020 at 6:13 PM Mark Thomas <ma...@apache.org> wrote:
> On 26/03/2020 16:47, Rémy Maucherat wrote: > > On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat <r...@apache.org > > <mailto:r...@apache.org>> wrote: > > > > - Remove the use of system properties to control configuration > > wherever possible. > > I still don't see the point for quite a few of them. For others > > however, using sys props was a mistake, example the facade > > recycling. Also, the digester can now pull from system and env > > properties, giving full flexibility. Also also, this is a handy way > > to do things in cloud. I think we should target the ones which > > should make sense. > > > > > > I think I'm done with that area for now as I'm a bit skeptical about > > this for JULI, EL, JSP and Websockets. Any reasonable candidates for > > removal left ? > Ok, so all are now done except: > > Digester > - Not sure. Likely to be tricky > > Clustering > - org.apache.catalina.tribes.dns_lookups > Any DNS names are going to *have* to be resolved at some point for > the cluster to work. I'd probably remove this and let the user > specify DNS name or IP address as they wish. > This one. I'd remove it outright. > > EL > - Can't do anything about these without spec changes > > Jasper > - Could all move to o.a.jasper.Options > > Security > - ALLOW_BACKSLASH > Remove it. It is just wrong. If we must keep it, move it to the > Connector. > - ALLOW_ENCODED_SLASH > I plan to replace this with a Connector option > > Spec > - STRICT_SERVLET_COMPLIANCE > Is a useful short-cut > I would prefer keeping it (useful shortcut indeed), even though it might be technically feasible to remove it. > - Move the remaining ones to the Context or related object where > possible (I haven't checked how easy that would be) > > Sessions > - Move to the Manager or related object where possible (I haven't > checked how easy that would be) > > JULI > - Look tricky to remove any of these. > > JAR Scanning > - Leave as is > > WebSockets > - Ideally want to set these per web app but we'd need to find a > configuration mechanism to use > Not done yet. > > Other > - Looks like NioSelectorShared has already been refactored out. > - The rest look difficult to remove. > Yes, the rest are either impossible to remove, or super legacy ways to set default values and possibly "widely" used [looking at something like "jvmRoute", "catalina.config" or "catalina.useNaming" for example]. Rémy
