Doesn't the same applies? It is a finite product (and not too big). The only choice to do is how to expose it I guess.
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 jeu. 16 avr. 2020 à 14:34, Rémy Maucherat <r...@apache.org> a écrit : > 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 >>>> >>>
