On Thu, Apr 16, 2020 at 1:42 PM Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 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. > The get/set are methods that could/would be removed of course, but I haven't even done it at all right now. The problem is the object creation and how and when they get tied together. Rémy > > > 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 >>> >>
