You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2018/06/08 14:10:41 UTC
svn commit: r1833172 - /tomcat/trunk/TOMCAT-NEXT.txt
Author: markt
Date: Fri Jun 8 14:10:40 2018
New Revision: 1833172
URL: http://svn.apache.org/viewvc?rev=1833172&view=rev
Log:
Remove the entries that were implemented for 9.0.x and add a few of the ideas that have been discussed for 10.0.x.
Modified:
tomcat/trunk/TOMCAT-NEXT.txt
Modified: tomcat/trunk/TOMCAT-NEXT.txt
URL: http://svn.apache.org/viewvc/tomcat/trunk/TOMCAT-NEXT.txt?rev=1833172&r1=1833171&r2=1833172&view=diff
==============================================================================
--- tomcat/trunk/TOMCAT-NEXT.txt (original)
+++ tomcat/trunk/TOMCAT-NEXT.txt Fri Jun 8 14:10:40 2018
@@ -15,45 +15,26 @@
limitations under the License.
================================================================================
-Notes of things to consider for the next major Tomcat release (9.0.x)
+Notes of things to consider for the next major Tomcat release (10.0.x)
- 1. DONE.
- Fix Java 8 Javadoc warnings.
+Items carried over from the 9.0.x list:
- 2. DONE.
- Remove BIO AJP and HTTP connector.
-
- 3. DONE.
- Remove Comet support.
-
- 4. DONE.
- Refactor the connectors to minimise code duplication.
- - All implementation specific per connector code -> Endpoint
- - All implementation specific per connection code -> SocketWrapper
-
- 5. DONE
- SNI support for JSSE.
-
- 6. See what Java 8 language features we want to use.
+1. Remove the use of system properties to control configuration wherever
+ possible.
- 7. Connector refactoring required for HTTP/2 APIs that might be exposed in
- the Servlet API.
+2. 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.
- 8. Keep an eye on the other Java EE 8 EGs (no sign of any movement apart
- from the Servlet EG so far).
+3. Consider wrapping the SocketWrapper with a facade to detect / prevent
+ components retaining references longer than they should.
- 9. DONE
- Refactor WebSocket I/O to go directly to Tomcat's internals rather than via
- the Servlet API.
-10. Remove the use of system properties to control configuration wherever
- possible.
+New items for 10.0.x onwards:
-11. 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.
+1. Remove APR connector.
-12. Consider wrapping the SocketWrapper with a facade to detect / prevent
- components retaining references longer than they should.
+2. Remove org.apache.tomcat.jni and replace with the minimum necessary to
+ interface with OpenSSL and clones.
-13. Asynchronous NIO2 styled alternate HTTP/2 implementation. Frame parsing logic
- would be in completion handlers.
+3. Remove the ExtensionValidator and associated classes (assuming that the
+ minimum Java version is Java 9 or later).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1833172 - /tomcat/trunk/TOMCAT-NEXT.txt
Posted by Mark Thomas <ma...@apache.org>.
On 08/06/18 15:40, Rémy Maucherat wrote:
> On Fri, Jun 8, 2018 at 4:10 PM <ma...@apache.org> wrote:
>
>> +1. Remove the use of system properties to control configuration wherever
>> + possible.
>>
>
> Ok. My bad, I'm a recovering addict ... ;)
Grin.
>> +2. 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.
>>
>
> Ok. I'm not sure where though, just like that.
I think a lot of this will go away when the deprecated Connector code is
removed. Beyond that there are bits an pieces of duplication. I think of
this entry more as something to look at if there is some spare time at a
point where we can still change the API.
>> +3. Consider wrapping the SocketWrapper with a facade to detect / prevent
>> + components retaining references longer than they should.
>
> On the plus side, the components are privileged, so if something goes wrong
> it's the component's fault and not a security issue. It depends on how much
> use this gets ultimately. I suppose quite a bit moving forward, so there
> should be an option there. It's obviously going to be cheap too.
Agreed. This is more of a protect the apps from themselves feature.
>> +New items for 10.0.x onwards:
>>
>> +1. Remove APR connector.
>>
>> +2. Remove org.apache.tomcat.jni and replace with the minimum necessary to
>> + interface with OpenSSL and clones.
>>
>
> Yes, but I still have no answer for the assertion that APR is still the
> fastest connector. So this performance drop has to be accepted. On the plus
> side, I would say APR users are not a majority, so this could go well.
> Functionally, APR is now more a problem than a solution in Tomcat
> ("sendfile" done differently works well now).
I thought the most recent round of testing showed that the difference
was marginal for "NIO HTTP" vs "APR HTTP" and "NIO+OpenSSL" vs "NIO APR
HTTPS".
If that isn't the case then there is much less of a case for removing APR.
> Ideas:
> - Someone mentioned a new compiler API could be used in Jasper
> - An embedded 2 API ?
> - Whatever from the early work of the EE EG (reactive shiny thingies ?)
All sound good.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r1833172 - /tomcat/trunk/TOMCAT-NEXT.txt
Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Jun 8, 2018 at 4:10 PM <ma...@apache.org> wrote:
> +1. Remove the use of system properties to control configuration wherever
> + possible.
>
Ok. My bad, I'm a recovering addict ... ;)
>
> +2. 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.
>
Ok. I'm not sure where though, just like that.
>
> +3. Consider wrapping the SocketWrapper with a facade to detect / prevent
> + components retaining references longer than they should.
>
On the plus side, the components are privileged, so if something goes wrong
it's the component's fault and not a security issue. It depends on how much
use this gets ultimately. I suppose quite a bit moving forward, so there
should be an option there. It's obviously going to be cheap too.
>
> +New items for 10.0.x onwards:
>
> +1. Remove APR connector.
>
> +2. Remove org.apache.tomcat.jni and replace with the minimum necessary to
> + interface with OpenSSL and clones.
>
Yes, but I still have no answer for the assertion that APR is still the
fastest connector. So this performance drop has to be accepted. On the plus
side, I would say APR users are not a majority, so this could go well.
Functionally, APR is now more a problem than a solution in Tomcat
("sendfile" done differently works well now).
Ideas:
- Someone mentioned a new compiler API could be used in Jasper
- An embedded 2 API ?
- Whatever from the early work of the EE EG (reactive shiny thingies ?)
Rémy