Re: Remaining Tomcat 10 items

[Mark Thomas]

On 02/04/2020 15:02, Rémy Maucherat wrote:
> On Fri, Mar 27, 2020 at 6:13 PM Mark Thomas  > wrote:
> 
> On 26/03/2020 16:47, Rémy Maucherat wrote:
> > On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat  
> > >> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Rémy Maucherat]

On Fri, Mar 27, 2020 at 6:13 PM Mark Thomas  wrote:

> On 26/03/2020 16:47, Rémy Maucherat wrote:
> > On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat  > > 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

[Mark Thomas]

On 30/03/2020 20:27, Christopher Schultz wrote:
> Mark,
> 
> On 3/27/20 13:12, Mark Thomas wrote:
>> Spec - STRICT_SERVLET_COMPLIANCE Is a useful short-cut - Move the
>> remaining ones to the Context or related object where possible (I
>> haven't checked how easy that would be)
> 
> Would it be possible to have this available as a  option? It
> would basically just change all the default options for that one
> . How much spec-compliance behavior is maintained at levels
> higher than ?

At a quick glance, only the URIEncoding on the Connector.

Hang on. Servlet 4 (12.1) changed the default to UTF-8. We need to clean
up the code / docs in light of that. Once that is done it looks like
this might be moveable to the Context.

Mark


> I agree it IS a useful short-cut. But having it
> as a system property is quite ugly.


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 3/27/20 13:12, Mark Thomas wrote:
> Spec - STRICT_SERVLET_COMPLIANCE Is a useful short-cut - Move the
> remaining ones to the Context or related object where possible (I
> haven't checked how easy that would be)

Would it be possible to have this available as a  option? It
would basically just change all the default options for that one
. How much spec-compliance behavior is maintained at levels
higher than ? I agree it IS a useful short-cut. But having it
as a system property is quite ugly.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6CSDIACgkQHPApP6U8
pFiy3hAAgzJrDBBQvH3yLkKRMheDKsfQLqTfz0v38g2IMdD3p40NolL3NFjrRx+Q
SZtuzPPozo6vBgcncnjuxwe7mYPLQWm56j/fbcftppIIhfGVgA0pbD3u2iFDu1TE
zAYQBw0ZomCmB+YN/5OCM1li4Y9/aVMKfSm0SoT8jh1boSQ1TT/mWkMx8cATnMr0
nhSV4ALwB/5jkPSl78rCsSBqnBPNJig1zaNNwbkS6uW4bQcDHvGEIx0mfT/bcM0t
QTkClBy0zE+LeanigPPz0bKrA0Yo6VqhNA88hZYX1x7dNaY1872Mv9TLJZ7/g/z/
fxxM/KU+MUsW7l0XsaPvWYjmkqPRTpdyKhcroEAHmv/ZEcPGvomxLLLoculoYOmY
IARFR7w+XXJ4f0FGNV0/OZmCLqJZG/wZyweKOyTjfnPV7HtzNJNPnnJa8k19934H
bIwlziyk/Y5fUAoz8pPtMvsl5+lRSSTgqOZnQITioMdEhAve1SG8kaKDrQ29cKGk
dFFgcfcC8Z9+74yQ5nCnP9JOprI/N9A695zQzo4mcu3VgxaigrqoU23m+yZRCCY5
GZr6OOCIH96/XjAivdbtwa79ga01FDPxsiF4RQD2W+f2tR1Otkn7FQ6vaDjLok4s
4ZmGiISBwrNFiULmHnOZqdvqCeWgkxkUtYoJguDSUykz3/b0M9E=
=ULKX
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Rémy Maucherat]

On Fri, Mar 27, 2020 at 6:13 PM Mark Thomas  wrote:

> On 26/03/2020 16:47, Rémy Maucherat wrote:
> > On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat  > > 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 ?
>
> Digester
>  - Not sure. Likely to be tricky
>

That sounds impossible since it happens before parsing of server.xml, so no
real way to configure besides system properties.


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

Ok. I think it's totally useless so I chose not to care about it ;)


>
> EL
>  - Can't do anything about these without spec changes
>
> Jasper
>  - Could all move to o.a.jasper.Options
>

Possibly yes. Quite a bit of work there.

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

I moved both to the Connector already, they can be removed as needed.


>
> Spec
>  - STRICT_SERVLET_COMPLIANCE
>Is a useful short-cut
>

+1


>  - Move the remaining ones to the Context or related object where
>possible (I haven't checked how easy that would be)
>

I moved them to Context.


>
> Sessions
>  - Move to the Manager or related object where possible (I haven't
>checked how easy that would be)
>

I moved them to Manager.

>
> 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
>
> Other
>  - Looks like NioSelectorShared has already been refactored out.
>

Yes, I removed that one from the doc.


>  - The rest look difficult to remove.
>

Rémy


>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Remaining Tomcat 10 items

[Mark Thomas]

On 26/03/2020 16:47, Rémy Maucherat wrote:
> On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat  > 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 ?

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.

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

Other
 - Looks like NioSelectorShared has already been refactored out.
 - The rest look difficult to remove.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Mark Thomas]

On 27/03/2020 16:13, Rémy Maucherat wrote:
> On Fri, Mar 27, 2020 at 4:54 PM Mark Thomas  > wrote:
> 
> On 25/03/2020 13:43, Rémy Maucherat wrote:
> > On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas  
> > >> wrote:
> >
> >     > - Reduce instances of setters and getters for the same property
> >     existing
> >     > on an object and its parent. This may require new objects to be
> >     exposed
> >     > via JMX.
> >     > Fixed enough ?
> >
> >     From memory, this was primarily on the Connectors. That is
> certainly a
> >     lot better. I'd like to review things before closing this one out.
> >
> >
> > There's indeed a problem on Connector, but I don't see how to fix it.
> >
> > Ex:
> >     public void setMaxPostSize(int maxPostSize) {
> >         this.maxPostSize = maxPostSize;
> >         setProperty("maxPostSize", String.valueOf(maxPostSize));
> >     }
> >
> > Both Catalina and Coyote need to access the value. The alternative
> would
> > be to have the Catalina code use getProperty, which would be both
> uglier
> > and slower.
> 
> I don't see any use of that particular property in Coyote. I think the
> setProperty() call can be removed.
> 
> 
> :D
> Grep confirms that we can remove the setProperty. Ok, that was a
> horrible example, but a few others in Connector are useful in both (like
> maxSavePostSize, which is one I looked at, then I wrote the post talking
> about maxPostSize).

The ones we need to keep are (I think):

asyncTimeout
maxSavePostSize
port
portOffset
localPort
secure

In terms of simplification, we could leave them as is or:
- Add them to ProtocolHandler
- Refactor Connector to pass the getter/setter calls to the
  ProtocolHandler instance.

I'm currently running a set of unit tests with the other setProperty()
calls removed to confirm I haven't missed anything.

I haven't looked elsewhere yet.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Rémy Maucherat]

On Fri, Mar 27, 2020 at 4:54 PM Mark Thomas  wrote:

> On 25/03/2020 13:43, Rémy Maucherat wrote:
> > On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas  > > wrote:
> >
> > > - Reduce instances of setters and getters for the same property
> > existing
> > > on an object and its parent. This may require new objects to be
> > exposed
> > > via JMX.
> > > Fixed enough ?
> >
> > From memory, this was primarily on the Connectors. That is certainly
> a
> > lot better. I'd like to review things before closing this one out.
> >
> >
> > There's indeed a problem on Connector, but I don't see how to fix it.
> >
> > Ex:
> > public void setMaxPostSize(int maxPostSize) {
> > this.maxPostSize = maxPostSize;
> > setProperty("maxPostSize", String.valueOf(maxPostSize));
> > }
> >
> > Both Catalina and Coyote need to access the value. The alternative would
> > be to have the Catalina code use getProperty, which would be both uglier
> > and slower.
>
> I don't see any use of that particular property in Coyote. I think the
> setProperty() call can be removed.
>

:D
Grep confirms that we can remove the setProperty. Ok, that was a horrible
example, but a few others in Connector are useful in both (like
maxSavePostSize, which is one I looked at, then I wrote the post talking
about maxPostSize).


>
> I'm not so sure I'll be able to do that for all the similar calls but
> I'll take a look.
>
> Context was another area where there has been a lot of this. I'll look
> there too.
>
> What I probably need to is start making a note of them when I see them
> and deal with them at the next refactoring opportunity.
>

Ok.

Rémy

Re: Remaining Tomcat 10 items

[Mark Thomas]

On 25/03/2020 13:43, Rémy Maucherat wrote:
> On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas  > wrote:
> 
> > - Reduce instances of setters and getters for the same property
> existing
> > on an object and its parent. This may require new objects to be
> exposed
> > via JMX.
> > Fixed enough ?
> 
> From memory, this was primarily on the Connectors. That is certainly a
> lot better. I'd like to review things before closing this one out.
> 
> 
> There's indeed a problem on Connector, but I don't see how to fix it.
> 
> Ex:
>     public void setMaxPostSize(int maxPostSize) {
>         this.maxPostSize = maxPostSize;
>         setProperty("maxPostSize", String.valueOf(maxPostSize));
>     }
> 
> Both Catalina and Coyote need to access the value. The alternative would
> be to have the Catalina code use getProperty, which would be both uglier
> and slower.

I don't see any use of that particular property in Coyote. I think the
setProperty() call can be removed.

I'm not so sure I'll be able to do that for all the similar calls but
I'll take a look.

Context was another area where there has been a lot of this. I'll look
there too.

What I probably need to is start making a note of them when I see them
and deal with them at the next refactoring opportunity.

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Rémy Maucherat]

On Mon, Mar 23, 2020 at 10:37 AM Rémy Maucherat  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 ?

Rémy

Re: Remaining Tomcat 10 items

[Rémy Maucherat]

On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas  wrote:

> > - Reduce instances of setters and getters for the same property existing
> > on an object and its parent. This may require new objects to be exposed
> > via JMX.
> > Fixed enough ?
>
> From memory, this was primarily on the Connectors. That is certainly a
> lot better. I'd like to review things before closing this one out.
>

There's indeed a problem on Connector, but I don't see how to fix it.

Ex:
public void setMaxPostSize(int maxPostSize) {
this.maxPostSize = maxPostSize;
setProperty("maxPostSize", String.valueOf(maxPostSize));
}

Both Catalina and Coyote need to access the value. The alternative would be
to have the Catalina code use getProperty, which would be both uglier and
slower.

Rémy

Re: Remaining Tomcat 10 items

[Rémy Maucherat]

On Mon, Mar 23, 2020 at 11:11 AM Mark Thomas  wrote:

> On 23/03/2020 09:37, Rémy Maucherat wrote:
> > Hi,
> >
> > I'm looking at the TODO list, in addition to some extra items. In order
> ...
> >
> > - Java 11.
> > I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be]
> > required for Tomcat 10 ? It could be better to do it in 10.1.
>
> No. It will be Java 8.
>
> > - 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.
>
> For "wherever possible" read "where it makes sense to do so". My
> intention was to target those system properties that were targetted at a
> specific component and could/should be configured there.
>
> > - Reduce instances of setters and getters for the same property existing
> > on an object and its parent. This may require new objects to be exposed
> > via JMX.
> > Fixed enough ?
>
> From memory, this was primarily on the Connectors. That is certainly a
> lot better. I'd like to review things before closing this one out.
>
> > - Remove APR connector.
> > Is there still general approval for that, and is that still the plan for
> > Tomcat 10.0 ?
>
> It feels like a big step but I do think this is the right thing to do.
>
> > - Clean-up content-type header processing.
> > No opinion on that.
>
> It fixes an edge case bug. I have a plan for this. As long as it is done
> before things go stable there is no rush.
>
> > - RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT
> > equivalent to the decoded form. Provide an option not to decode
> > delimiters in %nn form.
> > Mark is working on it.
>
> I'm close to a patch for this but I got distracted with HTTP/0.9 issues.
>
> > - Refactor DefaultServlet to use Ranges in parseRanges().
> > I looked at it and I don't get it.
> > In particular the Content-Ranges header
> > (https://tools.ietf.org/html/rfc7233#section-4.2) that uses
> >
> https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/http/parser/ContentRange.java#L75
> > The parser here requires a '=' but that should be a space in
> > content-range (ranges uses the '=' however), the example given in the
> > spec is "Content-Range: bytes 42-1233/1234".
> > Just wondering before starting to refactor.
>
> That is the response header, not the request header. Take a look at
> sections 2.1 and 3.1
>

Right, I had forgotten that. Fun stuff.
I hope I didn't break anything with that refactoring ...

Rémy


>
> Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
>

Re: Remaining Tomcat 10 items

[Michael Osipov]

Am 2020-03-23 um 10:37 schrieb Rémy Maucherat:

Hi,

I'm looking at the TODO list, in addition to some extra items. In order ...


You missed one point:

Remove deprecated code marked for removal in Tomcat 10.

M


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Michael Osipov]

Am 2020-03-23 um 15:42 schrieb Christopher Schultz:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 3/23/20 05:37, Rémy Maucherat wrote:

I'm looking at the TODO list, in addition to some extra items. In
order ...

- Remove APR connector. Is there still general approval for that,
and is that still the plan for Tomcat 10.0 ?


See the thread "[PROPOSAL] Tomcat 10: Drop AJP Connector" from
2019-10-07 and later. All replies were in favor of dropping AJP
support, though there were not a large number of those replies.
(michael-o had a concern about some performance problem in the HTTP
connector(s) but it seems that was a regression that was corrected
immediately after it was reported.)


It was a misconfiguration of the tests on master. With Mark's test code 
I was able to find the minimal required buffer size for three operating 
systems.


I will run master tests on several OSes and OpenJDK versions again and 
compare numbers. If they are significantly different, I will report them.


M


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rémy,

On 3/23/20 05:37, Rémy Maucherat wrote:
> I'm looking at the TODO list, in addition to some extra items. In
> order ...
>
> - Remove APR connector. Is there still general approval for that,
> and is that still the plan for Tomcat 10.0 ?

See the thread "[PROPOSAL] Tomcat 10: Drop AJP Connector" from
2019-10-07 and later. All replies were in favor of dropping AJP
support, though there were not a large number of those replies.
(michael-o had a concern about some performance problem in the HTTP
connector(s) but it seems that was a regression that was corrected
immediately after it was reported.)

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl54ytUACgkQHPApP6U8
pFj81A//QoeYRkzDCw/acYy1FOlrWGapDnvP/Am4sr4UDtcMjjLpGP7SyhMv2EOE
k5ndZ7xO+WFpzGVa13a5kzfrHGUt2m3mbZDMpkLsW2x55FUfq+Oe3g4e8g0Bjsmw
5zVwoOWuap+6wRN3dqNAQ3ZAPDBSz62xocY+daqNtmnKijmqyAMIxL4bqzRHaVQW
dpJeWRCQ2W4eg66594HSr59qfJ1XyiXH8jLYxEHvDA1+ilCOZC+hCBLvGO24KUx3
yJhc6ZbnQKhvb9W9tG1x8jls3H571ySno5dQ7YSFultv+dTtSNPL6dmS0stTCeNH
KvlJbwEip/ic1at3osr6Ua4Zq/IWSuedt7mRoXWx2M8SEldGTOY1HoM7ZB1jzcK+
25A46rq7knctJ1zDw5UXwL3s91qP7y1pwjCdX6UCfiu0XQg80VUXDKv1HiGH1aj1
lGxzG/INEios8SBHUpKKuXvDfd8Sm/z54VQSlvmBr817eX3ljdb1XR6o/Ld1KmiC
1eutQyZ2vIWBD3sR8BEum+9FvQ/XpINArSirC/DQVHP0TfInQlQq60dry4OjPFX2
delqCOM6pyVur9I362HKwgPXHHAGwdx8mWpC536nsNw3m0YMdW3dVImjbtz9nZ3H
GSeGziYslnKHAh8WmH5UxHJL59BXFTCTMUOOvIqsZkWDH3UuWmk=
=31Oo
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: Remaining Tomcat 10 items

[Mark Thomas]

On 23/03/2020 09:37, Rémy Maucherat wrote:
> Hi,
> 
> I'm looking at the TODO list, in addition to some extra items. In order ...
> 
> - Java 11.
> I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be]
> required for Tomcat 10 ? It could be better to do it in 10.1.

No. It will be Java 8.

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

For "wherever possible" read "where it makes sense to do so". My
intention was to target those system properties that were targetted at a
specific component and could/should be configured there.

> - Reduce instances of setters and getters for the same property existing
> on an object and its parent. This may require new objects to be exposed
> via JMX.
> Fixed enough ?

>From memory, this was primarily on the Connectors. That is certainly a
lot better. I'd like to review things before closing this one out.

> - Remove APR connector.
> Is there still general approval for that, and is that still the plan for
> Tomcat 10.0 ?

It feels like a big step but I do think this is the right thing to do.

> - Clean-up content-type header processing.
> No opinion on that.

It fixes an edge case bug. I have a plan for this. As long as it is done
before things go stable there is no rush.

> - RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT
> equivalent to the decoded form. Provide an option not to decode
> delimiters in %nn form.
> Mark is working on it.

I'm close to a patch for this but I got distracted with HTTP/0.9 issues.

> - Refactor DefaultServlet to use Ranges in parseRanges().
> I looked at it and I don't get it.
> In particular the Content-Ranges header
> (https://tools.ietf.org/html/rfc7233#section-4.2) that uses
> https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/http/parser/ContentRange.java#L75
> The parser here requires a '=' but that should be a space in
> content-range (ranges uses the '=' however), the example given in the
> spec is "Content-Range: bytes 42-1233/1234".
> Just wondering before starting to refactor.

That is the response header, not the request header. Take a look at
sections 2.1 and 3.1

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Remaining Tomcat 10 items

[Rémy Maucherat]

Hi,

I'm looking at the TODO list, in addition to some extra items. In order ...

- Java 11.
I suppose Jakarta EE 9 will require Java 11, is Java 11 [going to be]
required for Tomcat 10 ? It could be better to do it in 10.1.

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

- Reduce instances of setters and getters for the same property existing on
an object and its parent. This may require new objects to be exposed via
JMX.
Fixed enough ?

- Remove APR connector.
Is there still general approval for that, and is that still the plan for
Tomcat 10.0 ?

- Clean-up content-type header processing.
No opinion on that.

- RFC 3986 states (section 2.2) that a %nn encoded delimiter is NOT
equivalent to the decoded form. Provide an option not to decode delimiters
in %nn form.
Mark is working on it.

- Refactor DefaultServlet to use Ranges in parseRanges().
I looked at it and I don't get it.
In particular the Content-Ranges header (
https://tools.ietf.org/html/rfc7233#section-4.2) that uses
https://github.com/apache/tomcat/blob/master/java/org/apache/tomcat/util/http/parser/ContentRange.java#L75
The parser here requires a '=' but that should be a space in content-range
(ranges uses the '=' however), the example given in the spec is
"Content-Range: bytes 42-1233/1234".
Just wondering before starting to refactor.

Rémy