Re: API Change - Connector.java Constructor

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 | Blog | Old Blog | Github

Re: API Change - Connector.java Constructor

On Thu, Apr 16, 2020 at 1:42 PM Romain Manni-Bucau 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

Re: API Change - Connector.java Constructor

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 b

Re: API Change - Connector.java Constructor

On Fri, Apr 10, 2020 at 6:32 PM Filip Hanik wrote: > > > On Fri, Apr 10, 2020 at 1:28 AM Rémy Maucherat 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 >>> functi

Re: API Change - Connector.java Constructor

On Fri, Apr 10, 2020 at 1:28 AM Rémy Maucherat 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 >

Re: API Change - Connector.java Constructor

On Thu, Apr 9, 2020 at 7:54 PM Filip Hanik wrote: > Thanks Remy, > > On Wed, Apr 8, 2020 at 8:48 AM Rémy Maucherat wrote: > >> >>> >> If we want to improve on the Connector situation regarding duplication >> and reflection abuse, the only solution is to expose the different objects >> involved.

Re: API Change - Connector.java Constructor

Thanks Remy, On Wed, Apr 8, 2020 at 8:48 AM Rémy Maucherat wrote: > >> > If we want to improve on the Connector situation regarding duplication and > reflection abuse, the only solution is to expose the different objects > involved. > > Since an example is usually better, I'll give one using ser

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 8:42 PM Mark Thomas wrote: > On 07/04/2020 19:03, Filip Hanik wrote: > > > > > > On Tue, Apr 7, 2020 at 9:35 AM Rémy Maucherat > > wrote: > > > > > > Does the connector need to know about the actual implementations? > > > > > > Ideally n

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 8:42 PM Mark Thomas wrote: > On 07/04/2020 19:03, Filip Hanik wrote: > > > > > > On Tue, Apr 7, 2020 at 9:35 AM Rémy Maucherat > > wrote: > > > > > > Does the connector need to know about the actual implementations? > > > > > > Ideally n

Re: API Change - Connector.java Constructor

On 07/04/2020 19:03, Filip Hanik wrote: > > > On Tue, Apr 7, 2020 at 9:35 AM Rémy Maucherat > wrote: > > > Does the connector need to know about the actual implementations? > > > Ideally no, but it removes the reflection you say is bad for Graal. > > > C

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 9:35 AM Rémy Maucherat wrote: > >> Does the connector need to know about the actual implementations? >> > > Ideally no, but it removes the reflection you say is bad for Graal. > Correct. Turns out that the connectors use setProperty/getProperty via reflection (Introspectio

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 5:22 PM Filip Hanik wrote: > On Tue, Apr 7, 2020 at 8:15 AM Rémy Maucherat wrote: > >> On Tue, Apr 7, 2020 at 10:16 AM Mark Thomas wrote: >> >>> > Noted, I think a compromise may be in order. Where we simply add a >>> > constructor that avoids the Class.forName >>> > and

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 8:15 AM Rémy Maucherat wrote: > On Tue, Apr 7, 2020 at 10:16 AM Mark Thomas wrote: > >> > Noted, I think a compromise may be in order. Where we simply add a >> > constructor that avoids the Class.forName >> > and that allows the developer to explicitly invoke a constructor

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 10:16 AM Mark Thomas wrote: > > Noted, I think a compromise may be in order. Where we simply add a > > constructor that avoids the Class.forName > > and that allows the developer to explicitly invoke a constructor that > > avoids it. > > My thinking was more along the follo

Re: API Change - Connector.java Constructor

On Tue, Apr 7, 2020 at 10:16 AM Mark Thomas wrote: > My thinking was more along the following lines... > > Rewrite the Connector (and possibly some/all other components) so that > If we're talking about embedded, then the other components don't have the problem. For example to create a context y

Re: API Change - Connector.java Constructor

On 06/04/2020 20:50, Filip Hanik wrote: > On Mon, Apr 6, 2020 at 11:20 AM Mark Thomas > wrote: > > On 06/04/2020 17:56, Filip Hanik wrote: > > Team, > > > > As I'm slowly transitioning between projects, Apache Tomcat has once > > again showed up in my

Re: API Change - Connector.java Constructor

On Mon, Apr 6, 2020 at 11:20 AM Mark Thomas wrote: > On 06/04/2020 17:56, Filip Hanik wrote: > > Team, > > > > As I'm slowly transitioning between projects, Apache Tomcat has once > > again showed up in my workspace. I'm currently working on improving the > > embedded experience for native images

Re: API Change - Connector.java Constructor

On 06/04/2020 17:56, Filip Hanik wrote: > Team, > > As I'm slowly transitioning between projects, Apache Tomcat has once > again showed up in my workspace. I'm currently working on improving the > embedded experience for native images. > > I have a pull request,[1]

API Change - Connector.java Constructor

Team, As I'm slowly transitioning between projects, Apache Tomcat has once again showed up in my workspace. I'm currently working on improving the embedded experience for native images. I have a pull request, [1] , that I'd like to open up a discussion a