Hi all, Just wanted to shout a proposal - hoping to not be too much "off".
I guess the target of bypassing reflection is mainly for what tomcat delivers - ie not the user/vendor extensions - so it means everything is there at build time, so why not generating the reflection-free API? Idea would be the following one: for each class "missing" setters (to bypass reflection), generate a <classname>$Accessors class extending the root one but with the accessors (the nested class enables to have access to private fields). Small trick: some $Accessors class must have multiple flavors, I'm thinking to transitive reflection (protocol handler) but since all the settable model is known at build time it is very doable. Simplest sounds using a first compilation pass, generation then compile new classes but using an annotation processor sounds doable as well. At the end, this means that then you can be fully reflection free using the generated classes instead of the standard one. Hope it makes sense and it is not too late. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mer. 15 avr. 2020 à 18:26, Rémy Maucherat <r...@apache.org> a écrit : > On Fri, Apr 10, 2020 at 6:32 PM Filip Hanik <fha...@pivotal.io> wrote: > >> >> >> On Fri, Apr 10, 2020 at 1:28 AM Rémy Maucherat <r...@apache.org> wrote: >> >>> >>> >>>> This configuration gives the impression that the Endpoint is a child of >>>> the Connector. >>>> But the Connector truly only needs the ProtocolHandler interface to >>>> function. The injected object would then be better to an instance of a >>>> ProtocolHandler >>>> >>>> The XML can of course be configured to instantiate and inject the >>>> ProtocolHandler handler directly into the Connector >>>> In this setting, it doesn't make sense to have any properties on the >>>> Connector, since the Connector receives the protocol handler already >>>> configured. >>>> >>>> <Connector scheme="https" secure="true"> >>>> <Protocol className="org.apache.coyote.http11.Http11Protocol" >>>> maxHeaderCount="10" > >>>> <Endpoint className="org.apache.tomcat.util.net.NioEndpoint" >>>> port="8443" SSLEnabled="true" >>>> >>>> >>>> sslImplementationName="org.apache.tomcat.util.net.openssl.OpenSSLImplementation"> >>>> <SocketProperties directBuffer="true" directSslBuffer="true" >>>> /> >>>> <SSLHostConfig honorCipherOrder="false"> >>>> <Certificate >>>> certificateKeyFile="${catalina.home}/conf/key.pem" >>>> >>>> certificateFile="${catalina.home}/conf/cert.pem" >>>> type="RSA" /> >>>> </SSLHostConfig> >>>> </Endpoint> >>>> <UpgradeProtocol >>>> className="org.apache.coyote.http2.Http2Protocol" /> >>>> <Protocol >>>> </Connector> >>>> >>> >>> Either way, I experimented a bit and it's not doable. Too many intrusive >>> changes and impossibility to be compatible. >>> >> >> Sounds good. >> > > I started working on it more to make a real attempt and see how it behaves > in practice. Even though the changes are problematic [the biggest > Catalina/Tomcat API break ever, surpassing the TLS configuration changes > earlier], the Connector is still the biggest problem for duplicated > properties and random hacks, including reflection abuse. That's a goal/todo > for 10 so it is worth doing it to put it on review to know if it exceeds > the pain threshold of most. > > Rémy > > >> >> Filip >> >
