On Thu, Apr 16, 2020 at 10:52 AM Mark Thomas <ma...@apache.org> wrote:
> On 15/04/2020 22:05, r...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
