You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2020/04/15 21:05:08 UTC
[tomcat] branch master updated: Proposed Connector API and XML
refactoring
This is an automated email from the ASF dual-hosted git repository.
remm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/tomcat.git
The following commit(s) were added to refs/heads/master by this push:
new 92923fe Proposed Connector API and XML refactoring
92923fe is described below
commit 92923febadb5d7901747530272302dc3da6311c2
Author: remm <re...@apache.org>
AuthorDate: Wed Apr 15 23:04:47 2020 +0200
Proposed Connector API and XML refactoring
See https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
The basics were relatively easy to do [the XML given in the JIRA is
functional] although I have lots of items to finish: testsuite, JMX,
storeconfig, some defaults todo, polish [a few shotnames for some class
names here and there], documentation (ouch). This is essentially the
only way to do to allow progress on the get/set duplication which is
quite prevalent in the connector API (in addition to a lot of other
cleanups), without this item 2 "Reduce instances of setters and getters
for the same property" on the list will have to be given up on.
Please indicate if this magnitude of changes is acceptable in Tomcat 10.
---
TOMCAT-NEXT.txt | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/TOMCAT-NEXT.txt b/TOMCAT-NEXT.txt
index 129a8c7..e535179 100644
--- a/TOMCAT-NEXT.txt
+++ b/TOMCAT-NEXT.txt
@@ -29,6 +29,10 @@ New items for 10.0.x onwards:
1. Remove APR connector.
+ 2. Connector API and XML refactoring
+ https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
+ for details.
+
Deferred until 10.1.x:
1. Remove the ExtensionValidator and associated classes (assuming that the
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML refactoring
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Apr 16, 2020 at 10:52 AM Mark Thomas <ma...@apache.org> wrote:
> On 15/04/2020 22:05, remm@apache.org wrote:
>
> <snip/>
>
> > Proposed Connector API and XML refactoring
>
> My first impression is that the cost for users is going to be high.
> Simple Connector configurations are more complicated.
>
> Is there a plan for a transition period like we had with the TLS changes
> where both configuration styles were support in parallel for a major
> version?
>
The whole problem is created by the Connector constructor that has to
create the ProtocolHandler and the other objects at the same time, to be
able to later pass all attributes using reflection. The change is to
transform that to regular beans with a normal lifecycle. It also allows
removing per IO API ProtocolHandler as there are no properties to pass
through to the corresponding endpoint and socket properties. Ultimately the
digester likes beans and a per object XML element, so every time you
deviate from that it adds complexity.
Compatibility seems possible to a large extent for server.xml, but at the
cost of having ugly code [basically properties are set in a HashMap of
Connector, actually set in init, and a few more digester rules]. For
embedded, it's probably less compatible but it would make things more
reliable for properties (strong typing).
For the simplest configurations, "port" and maybe "address" could remain
special attributes on the Connector class maybe. Not great but it's a
compromise.
I haven't added better compatibility yet [my code at the moment only
supports the new configuration], let me know if this refactoring is worth
pursuing at all.
>
> What are the reasons behind the change? If the only reason is to remove
> complexity / boilerplate from the Connector and friends then I think it
> would be better for us accept those costs as maintainers rather than
> expose users to this change (which itself would create costs for us
> explaining the change anyway).
>
Ok fair enough, the item from TOMCAT-NEXT about removing the get/set should
be dropped then.
>
> How much is Graal a factor here? What benefits does this change provide
> to Graal users? I'll note that Graal does not appear to be an issue of
> concern to the user community at the moment. The only mentions of Graal
> on the users list are in release announcements.
>
No Graal factor at all, it works very well as is [reflection works ;) ].
Personally, I have no additional Graal items to do, I am done [except for
testing new Graal releases and adapting, there are always surprises ! so
it's rather fun to do in a way]. Tomcat standalone works except for the
areas that are not supported by the "Java" platform provided by Graal [no
serialization, so no clustering, and of course no JMX].
> Along the lines of the changes already made, are there other (small?)
> changes we could make that move things in this direction without the
> associated costs for users? I'm guessing not.
>
Not that I can think of, the boilerplate code exists to be able to put more
configuration on the Connector class even though it is not really there.
Rémy
> Mark
>
> >
> > See
> https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
> > The basics were relatively easy to do [the XML given in the JIRA is
> > functional] although I have lots of items to finish: testsuite, JMX,
> > storeconfig, some defaults todo, polish [a few shotnames for some
> class
> > names here and there], documentation (ouch). This is essentially the
> > only way to do to allow progress on the get/set duplication which is
> > quite prevalent in the connector API (in addition to a lot of other
> > cleanups), without this item 2 "Reduce instances of setters and
> getters
> > for the same property" on the list will have to be given up on.
> > Please indicate if this magnitude of changes is acceptable in Tomcat
> 10.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: [tomcat] branch master updated: Proposed Connector API and XML
refactoring
Posted by Mark Thomas <ma...@apache.org>.
On 15/04/2020 22:05, remm@apache.org wrote:
<snip/>
> Proposed Connector API and XML refactoring
My first impression is that the cost for users is going to be high.
Simple Connector configurations are more complicated.
Is there a plan for a transition period like we had with the TLS changes
where both configuration styles were support in parallel for a major
version?
What are the reasons behind the change? If the only reason is to remove
complexity / boilerplate from the Connector and friends then I think it
would be better for us accept those costs as maintainers rather than
expose users to this change (which itself would create costs for us
explaining the change anyway).
How much is Graal a factor here? What benefits does this change provide
to Graal users? I'll note that Graal does not appear to be an issue of
concern to the user community at the moment. The only mentions of Graal
on the users list are in release announcements.
Along the lines of the changes already made, are there other (small?)
changes we could make that move things in this direction without the
associated costs for users? I'm guessing not.
Mark
>
> See https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
> The basics were relatively easy to do [the XML given in the JIRA is
> functional] although I have lots of items to finish: testsuite, JMX,
> storeconfig, some defaults todo, polish [a few shotnames for some class
> names here and there], documentation (ouch). This is essentially the
> only way to do to allow progress on the get/set duplication which is
> quite prevalent in the connector API (in addition to a lot of other
> cleanups), without this item 2 "Reduce instances of setters and getters
> for the same property" on the list will have to be given up on.
> Please indicate if this magnitude of changes is acceptable in Tomcat 10.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML
refactoring
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-04-17 um 16:58 schrieb Rémy Maucherat:
> On Fri, Apr 17, 2020 at 2:19 PM Michael Osipov <mi...@apache.org> wrote:
>
>> Isn't that obvious a soon as I provide
>> sslImplementationName/<SSLHostConfig />?
>>
>
> With the new config SSLHostConfig, SSLEnabled seems to be derivable from
> that since it's mandatory. This wasn't practical before. However, I see
> code that also checks the flag in addSslHostConfig. So I am still not
> comfortable removing it right now.
>
> So since there seems to be continued skepticism about the new XML, the best
> seems to be to do nothing.
I am not really skeptical about it, all I am saying is that redundant
stuff should be dropped and the configuration should be straight
forward. Your idea goes in the right way.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML refactoring
Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Apr 17, 2020 at 2:19 PM Michael Osipov <mi...@apache.org> wrote:
> Isn't that obvious a soon as I provide
> sslImplementationName/<SSLHostConfig />?
>
With the new config SSLHostConfig, SSLEnabled seems to be derivable from
that since it's mandatory. This wasn't practical before. However, I see
code that also checks the flag in addSslHostConfig. So I am still not
comfortable removing it right now.
So since there seems to be continued skepticism about the new XML, the best
seems to be to do nothing.
Rémy
Re: [tomcat] branch master updated: Proposed Connector API and XML
refactoring
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-04-17 um 14:02 schrieb Rémy Maucherat:
> On Fri, Apr 17, 2020 at 11:51 AM Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2020-04-15 um 23:05 schrieb remm@apache.org:
>>> This is an automated email from the ASF dual-hosted git repository.
>>>
>>> remm pushed a commit to branch master
>>> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>>>
>>>
>>> The following commit(s) were added to refs/heads/master by this push:
>>> new 92923fe Proposed Connector API and XML refactoring
>>> 92923fe is described below
>>>
>>> commit 92923febadb5d7901747530272302dc3da6311c2
>>> Author: remm <re...@apache.org>
>>> AuthorDate: Wed Apr 15 23:04:47 2020 +0200
>>>
>>> Proposed Connector API and XML refactoring
>>>
>>> See
>> https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
>>
>> To add some fuel to the fire: This looks like a start.
>>
>> I always liked the approach HTTPd took, addd a Listen <IP>:<Port> +
>> VirtualHost <IP>:<Port>.
>>
>> Even in the new proposal you have redundancies: scheme, secure,
>> SSLEnabled. Why can't the endpoint or rather a class using this endpoint
>>
>
> There's actually no duplication with these attributes.
> SSLEnabled: actually use TLS on the connector
Isn't that obvious a soon as I provide
sslImplementationName/<SSLHostConfig />?
> secure: Tomcat considers the data received from the client has been kept
> secure end to end
Is that so? How can I guarantee -- as a client -- that a middle box
(forwarding proxy) enforces secure comminication?
Docs say this:
> Set this attribute to true if you wish to have calls to request.isSecure() to return true for requests received by this Connector.
> scheme: the protocol scheme to be used on the URL (http or https basically)
This is determined/implied by the protocol handler you use. Saying:
> <Connector scheme="https"
and
> <UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />
looks just wrong because with ALPN it won't be https, but h2. No TLS is
used, you still can try h2c directly if you know upfront.
From an admin point of view, this is messy and confusing. Always
consider that admins aren't devs. Our admins keeps asking me things
about Tomcat config options because they are beyond his understanding as
an admin.
>>
>> My understanding is:
>>
>> * An endpoint impl is a pure socket which can run any protocol
>> * A protocol is uses an endpoint
>> * A Host declares to use a specific endpoint/protocol
>> * Either proto or host declare TLS
>> Which such decoupling one could even introduce AJPS.
>>
>> But a guess this is a lot of work to do.
>>
>
> Indeed that's not what we do. I guess everyone involved with Catalina was
> skeptical and considered the current nested container structure was
> flexible enough.
Having said that, I don't think it is flexible enough. It is flexible at
places not strictly requiring it while in others limited.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: [tomcat] branch master updated: Proposed Connector API and XML refactoring
Posted by Rémy Maucherat <re...@apache.org>.
On Fri, Apr 17, 2020 at 11:51 AM Michael Osipov <mi...@apache.org> wrote:
> Am 2020-04-15 um 23:05 schrieb remm@apache.org:
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > remm pushed a commit to branch master
> > in repository https://gitbox.apache.org/repos/asf/tomcat.git
> >
> >
> > The following commit(s) were added to refs/heads/master by this push:
> > new 92923fe Proposed Connector API and XML refactoring
> > 92923fe is described below
> >
> > commit 92923febadb5d7901747530272302dc3da6311c2
> > Author: remm <re...@apache.org>
> > AuthorDate: Wed Apr 15 23:04:47 2020 +0200
> >
> > Proposed Connector API and XML refactoring
> >
> > See
> https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
>
> To add some fuel to the fire: This looks like a start.
>
> I always liked the approach HTTPd took, addd a Listen <IP>:<Port> +
> VirtualHost <IP>:<Port>.
>
> Even in the new proposal you have redundancies: scheme, secure,
> SSLEnabled. Why can't the endpoint or rather a class using this endpoint
>
There's actually no duplication with these attributes.
SSLEnabled: actually use TLS on the connector
secure: Tomcat considers the data received from the client has been kept
secure end to end
scheme: the protocol scheme to be used on the URL (http or https basically)
> decide what protocol it speaks when TLS config is nested?
> What I never understood with Tomcat why Host configs applies to *all*
> connectors. I cannot freely apply hosts to IP/port combos and selecting
> on a host level what type of protocol I want to have.
>
The refactoring reflects the object structure, because that's how the
digester works. There's a slight change to the Connector lifecycle. That's
it for this one, the object structure is actually unchanged.
I made progress and I think the old XML can be supported. For embedded, old
code can be mostly supported too. It would break if trying to manipulate
too directly the protocol handler, but normally embedded code uses new
Connector(protocol) and sets properties there, so it would work.
It would mean keeping the messy code in 10.0, actually adding new code in
parallel, but a large cleanup could then occur in 10.1.
>
> My understanding is:
>
> * An endpoint impl is a pure socket which can run any protocol
> * A protocol is uses an endpoint
> * A Host declares to use a specific endpoint/protocol
> * Either proto or host declare TLS
> Which such decoupling one could even introduce AJPS.
>
> But a guess this is a lot of work to do.
>
Indeed that's not what we do. I guess everyone involved with Catalina was
skeptical and considered the current nested container structure was
flexible enough.
Rémy
>
> M
>
Re: [tomcat] branch master updated: Proposed Connector API and XML
refactoring
Posted by Michael Osipov <mi...@apache.org>.
Am 2020-04-15 um 23:05 schrieb remm@apache.org:
> This is an automated email from the ASF dual-hosted git repository.
>
> remm pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/tomcat.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 92923fe Proposed Connector API and XML refactoring
> 92923fe is described below
>
> commit 92923febadb5d7901747530272302dc3da6311c2
> Author: remm <re...@apache.org>
> AuthorDate: Wed Apr 15 23:04:47 2020 +0200
>
> Proposed Connector API and XML refactoring
>
> See https://cwiki.apache.org/confluence/display/TOMCAT/Connector+API+refactoring
To add some fuel to the fire: This looks like a start.
I always liked the approach HTTPd took, addd a Listen <IP>:<Port> +
VirtualHost <IP>:<Port>.
Even in the new proposal you have redundancies: scheme, secure,
SSLEnabled. Why can't the endpoint or rather a class using this endpoint
decide what protocol it speaks when TLS config is nested?
What I never understood with Tomcat why Host configs applies to *all*
connectors. I cannot freely apply hosts to IP/port combos and selecting
on a host level what type of protocol I want to have.
My understanding is:
* An endpoint impl is a pure socket which can run any protocol
* A protocol is uses an endpoint
* A Host declares to use a specific endpoint/protocol
* Either proto or host declare TLS
Which such decoupling one could even introduce AJPS.
But a guess this is a lot of work to do.
M
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org