You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rémy Maucherat <re...@apache.org> on 2020/04/02 14:02:13 UTC
Re: Remaining Tomcat 10 items
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 <remm@apache.org
> > <ma...@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
Re: Remaining Tomcat 10 items
Posted by Mark Thomas <ma...@apache.org>.
On 02/04/2020 15:02, Rémy Maucherat wrote:
> On Fri, Mar 27, 2020 at 6:13 PM Mark Thomas <markt@apache.org
> <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 <remm@apache.org
> <ma...@apache.org>
> > <mailto:remm@apache.org <ma...@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:
Nice.
> 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.
I agree. Deprecate it in 10, back-port and then remove it in 10.
I can do this next as I have just finished going through the open PRs.
> 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.
It looks like this could be made per web application if we wanted.
Whether there is a need to do that (keeping the system property as the
default) is TBD. I don't recall any requests to do that so maybe wiat
until we get one.
> - 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.
ServletContext initialisation parameters come to mind but I need to
check how accessible they are from the code that needs to use the
configuration. I think that might be something for M5.
> 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].
Agreed.
What we have though is a huge improvement on where things were. Thanks
for all you have done on this.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org