On Tue, Apr 7, 2020 at 8:15 AM Rémy Maucherat <r...@apache.org> wrote:
> On Tue, Apr 7, 2020 at 10:16 AM Mark Thomas <ma...@apache.org> 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 following lines...
>>
>> Rewrite the Connector (and possibly some/all other components) so that
>> if a known class name was specified, rather than using the specified
>> name directly via reflection we could do something like:
>>
>> if ("org.apache.coyote.http11.Http11NioProtocol".equals(className)) {
>> protocol = new Http11NioProtocol();
>> } else if ("org...
>> ...
>> } else {
>> // OK. Unrecognised class name. Use reflection
>> ...
>> }
>>
>> Would that style of approach help at all?
>>
>
> Proposed patch:
> https://pastebin.com/ydCYnBD9
>
That patch works, I would include the check for the full classname too
Was: if ("HTTP/1.1".equals(protocol) || protocol == null)
Could be: if (protocol == null || "HTTP/1.1".equals(protocol) ||
"HTTP/1.1".equals(Http11NioProtocol.class.getName))
However, what still is awkward is that Connector.java deals with the
interface ProtocolHandler.
The loading of both the Http11NioConnector and the Ajp13NioConnector seems
to defy the purpose of having that interface being present
Is: protected final ProtocolHandler protocolHandler;
Does the connector need to know about the actual implementations?
Filip
>
> Rémy
>
>
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
