Ok I will read these thank you.
So essentially you are saying that I can not get away by justo overriding the
new method delegating to the old one? I.e.
public ServerSocketFactory getServerSocketFactory(AbstractEndpoint endpoint){
return getServerSocketFactory();//the existing and worked fine in
older Tomcat version
}
and call my existing implementation and just ignore the endpoint parameter?
________________________________
From: Konstantin Kolinko <knst.koli...@gmail.com>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Thursday, July 5, 2012 3:25 PM
Subject: Re: Tomcat 7 and JIoEndpoint as used in ssl
2012/7/5 Hermes Flying <flyingher...@yahoo.com>:
> Hi,
>
> I have build a custom SSL implementation and I use that for the SSL
> connectivity in Tomcat.
> This was build back in Tomcat 5 and it works in Tomcat 6
> But now that we are trying to migrate in Tomcat 7 a change has been done that
> breaks my implementation.
> Specifically the
> org.apache.tomcat.util.netSSLImplementation#getServerSocketFactory() has been
> changed to
>
> org.apache.tomcat.util.netSSLImplementation#getServerSocketFactory(AbstractEndpoint
> endpoint)
> at least this is a first difference I found so far.
>
> My question is: What is the need/use of this change?
http://svn.apache.org/viewvc?view=revision&revision=1044058
> In the previous version (with no params) my implementation handled
> everything. Am I supposed to do something with the AbstractEndpoint endpoint?
> I see that this normally is JIoEndpoint. Am I supposed to pass some
> information back to it? Or has this been done just in case someone would need
> to do that.
org.apache.tomcat.util.net.jsse.JSSEImplementation extends SSLImplementation {
(...)
@Override
public ServerSocketFactory getServerSocketFactory(AbstractEndpoint
endpoint) {
return new JSSESocketFactory(endpoint);
}
}
and JSSESocketFactory uses endpoint a lot.
> What is the functionality of JIoEndpoint?
The same as of AbstractEndpoint plus a bit more.
Endpoint
1. represents the "server socket", on which Tomcat connector listens.
2. is responsible for socket management regardless of protocol (HTTP,
AJP), especially the "server socket" management.
3. naturally serves as the storage for certain set of configurations
options (the ones that are protocol-agnostic and ones that relate to
socket management).
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
