You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Mark Claassen (JIRA)" <ji...@apache.org> on 2011/02/18 15:39:38 UTC
[jira] Created: (HTTPCLIENT-1059) Allow for the on-demand creation
of a new SSLSocketFactory that wraps the
HttpsURLConnection.getDefaultSSLSocketFactory()
Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
-------------------------------------------------------------------------------------------------------------------------
Key: HTTPCLIENT-1059
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1059
Project: HttpComponents HttpClient
Issue Type: New Feature
Components: HttpClient
Affects Versions: 4.1 Final, 4.0.3, 3.1 Final
Environment: Applications using webstart
Reporter: Mark Claassen
Fix For: Future
I have been using HttpClient for a while now with success. However, I have recently encountering some problems which I think have an easy solution, although it is not accessible to me through the current API.
Situation (my test enviroment):
ServerA:
* Runs Tomcat 6
* Contains jar files that are downloaded via webstart
* Only accepts non-SSL connections
ServerB:
* Runs Tomcat 6
* Contains jar files that are downloaded via webstart
* Contains a servlet
* Only accepts SSL connections
If I connect to serverB (via webstart) to download the jars, my app connects to the servlet on ServerB and everything is fine.
However, if I connect to ServerA (via webstart) and then the app tries to connect to ServerB, the SSL connection cannot be established.
I believe this has to do with the underlying socket factory that is being used. This is crucial, since I need to use the default socket factory managed by webstart that automatically prompts for certificate issues and allows for automatic use of client certificates.
Theory
----------------
Terminology:
javax.SSLSocketFactory = javax.net.ssl.SSLSocketFactory
apache.SSLSocketFactory = org.apache.http.conn.ssl.SSLSocketFactory
I am not exactly sure what is happening, but I have a theory. In my theory, the crux of the problem is that the DEFAULT apache.SSLSocketFactory is set in the static initializer of the apache.SSLSocketFactory class. In the first scenario above, webstart creates a new javax.SSLSocketFactory for the jar download, and makes this the default. This happens before the apache.SSLSocketFactory class is loaded, and, therefore, before the static initializer is executed. In the second scenario, this happens in the other order and the javax.SSLSocketFactory wrapped by the apache.SSLSocketFactory is not the one used by webstart
I need to ensure that the javax.SSLSocketFactory is initialized (and replaced) first, and then create an apache.SSLSocketFactory to wrap this. The apache.SSLSocketFactory does have a wrapping construtor, but it is the private no-argument constructor. If this were public in some manner, I could create my apache.SSLSocketFactory after I was sure that the HttpsURLConnection default socket factory was the one I needed.
Theory Corroborated
--------------------
I downloaded the httpclient 4.01 source (the version we are currently using), changed the no-arg constructor to be public, and used it to create a new apache.SSLSocketFactory after I initialized the HttpsURLConnection. This did indeed solve the problem. Perhaps there is more going on here than I realize, but it was not complicated and it worked.
Another far easier work-around would be to do something like this:
Constructor<SSLSocketFactory> con = SSLSocketFactory.class.getConstructor((Class<?>[]) null);
con.setAccessible(true);
fact = con.newInstance((Object[])null);
RFE
-------------
Make the no-arg constructor public or provide access to it though another method
I don't really see a down-side to making the no-arg constructor public. However, if this needs to be private to prevent certain types of subclassing, a static method could be added to create an apache.SSLSocketFactory that wraps the default javax.SSLSocketFactory. If the constructor is private just for historical reasons, than it may be easier to just make it public.
If making the constructor public is undesirable for some reason, here is a recommendation for a change with minimal impact on the API and existing clients:
Add method createSocketFactory(), as:
public static SSLSocketFactory createSocketFactory() {
return new SSLSocketFactory();
}
This will:
1) Solve the problem
2) Preserve backwards compatibility
3) Encourage the new semantics
4) Ensure that any protections afforded by the private SSLSocketFactory constructor are still in place
In any case, after this change I think it is a good idea to deprecate the getSocketFactory() method. I would suspect that this method is not accessed frequently, so there is no real reason to optimize it in this way. I am also not sure if encouraging the use of a mutable* global shared socket factory is a good idea. If people want to use a particular socket factory, they should just create a new one, configure it how they want, and then keep it around to reuse as appropriate...without being in danger of another part of the application configuring it differently.
* It seems to be mutable only through a single deprecated method, however.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1059) Allow for the on-demand
creation of a new SSLSocketFactory that wraps the
HttpsURLConnection.getDefaultSSLSocketFactory()
Posted by "Mark Claassen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997425#comment-12997425 ]
Mark Claassen commented on HTTPCLIENT-1059:
-------------------------------------------
I am not exactly sure what you mean or how to do it. Do you want me to attache a diff to the changes I am purposing?
> Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1059
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1059
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient
> Affects Versions: 3.1 Final, 4.0.3, 4.1 Final
> Environment: Applications using webstart
> Reporter: Mark Claassen
> Labels: HttpsURLConnection, SSLSocketFactory, ssl, webstart
> Fix For: Future
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I have been using HttpClient for a while now with success. However, I have recently encountering some problems which I think have an easy solution, although it is not accessible to me through the current API.
> Situation (my test enviroment):
> ServerA:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Only accepts non-SSL connections
> ServerB:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Contains a servlet
> * Only accepts SSL connections
> If I connect to serverB (via webstart) to download the jars, my app connects to the servlet on ServerB and everything is fine.
> However, if I connect to ServerA (via webstart) and then the app tries to connect to ServerB, the SSL connection cannot be established.
> I believe this has to do with the underlying socket factory that is being used. This is crucial, since I need to use the default socket factory managed by webstart that automatically prompts for certificate issues and allows for automatic use of client certificates.
> Theory
> ----------------
> Terminology:
> javax.SSLSocketFactory = javax.net.ssl.SSLSocketFactory
> apache.SSLSocketFactory = org.apache.http.conn.ssl.SSLSocketFactory
> I am not exactly sure what is happening, but I have a theory. In my theory, the crux of the problem is that the DEFAULT apache.SSLSocketFactory is set in the static initializer of the apache.SSLSocketFactory class. In the first scenario above, webstart creates a new javax.SSLSocketFactory for the jar download, and makes this the default. This happens before the apache.SSLSocketFactory class is loaded, and, therefore, before the static initializer is executed. In the second scenario, this happens in the other order and the javax.SSLSocketFactory wrapped by the apache.SSLSocketFactory is not the one used by webstart
> I need to ensure that the javax.SSLSocketFactory is initialized (and replaced) first, and then create an apache.SSLSocketFactory to wrap this. The apache.SSLSocketFactory does have a wrapping construtor, but it is the private no-argument constructor. If this were public in some manner, I could create my apache.SSLSocketFactory after I was sure that the HttpsURLConnection default socket factory was the one I needed.
> Theory Corroborated
> --------------------
> I downloaded the httpclient 4.01 source (the version we are currently using), changed the no-arg constructor to be public, and used it to create a new apache.SSLSocketFactory after I initialized the HttpsURLConnection. This did indeed solve the problem. Perhaps there is more going on here than I realize, but it was not complicated and it worked.
> Another far easier work-around would be to do something like this:
> Constructor<SSLSocketFactory> con = SSLSocketFactory.class.getConstructor((Class<?>[]) null);
> con.setAccessible(true);
> fact = con.newInstance((Object[])null);
> RFE
> -------------
> Make the no-arg constructor public or provide access to it though another method
> I don't really see a down-side to making the no-arg constructor public. However, if this needs to be private to prevent certain types of subclassing, a static method could be added to create an apache.SSLSocketFactory that wraps the default javax.SSLSocketFactory. If the constructor is private just for historical reasons, than it may be easier to just make it public.
> If making the constructor public is undesirable for some reason, here is a recommendation for a change with minimal impact on the API and existing clients:
> Add method createSocketFactory(), as:
> public static SSLSocketFactory createSocketFactory() {
> return new SSLSocketFactory();
> }
> This will:
> 1) Solve the problem
> 2) Preserve backwards compatibility
> 3) Encourage the new semantics
> 4) Ensure that any protections afforded by the private SSLSocketFactory constructor are still in place
> In any case, after this change I think it is a good idea to deprecate the getSocketFactory() method. I would suspect that this method is not accessed frequently, so there is no real reason to optimize it in this way. I am also not sure if encouraging the use of a mutable* global shared socket factory is a good idea. If people want to use a particular socket factory, they should just create a new one, configure it how they want, and then keep it around to reuse as appropriate...without being in danger of another part of the application configuring it differently.
> * It seems to be mutable only through a single deprecated method, however.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1059) Allow for the on-demand
creation of a new SSLSocketFactory that wraps the
HttpsURLConnection.getDefaultSSLSocketFactory()
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12996739#comment-12996739 ]
Oleg Kalnichevski commented on HTTPCLIENT-1059:
-----------------------------------------------
Mark,
Can you submit a patch with the proposed changes?
Oleg
> Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1059
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1059
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient
> Affects Versions: 3.1 Final, 4.0.3, 4.1 Final
> Environment: Applications using webstart
> Reporter: Mark Claassen
> Labels: HttpsURLConnection, SSLSocketFactory, ssl, webstart
> Fix For: Future
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I have been using HttpClient for a while now with success. However, I have recently encountering some problems which I think have an easy solution, although it is not accessible to me through the current API.
> Situation (my test enviroment):
> ServerA:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Only accepts non-SSL connections
> ServerB:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Contains a servlet
> * Only accepts SSL connections
> If I connect to serverB (via webstart) to download the jars, my app connects to the servlet on ServerB and everything is fine.
> However, if I connect to ServerA (via webstart) and then the app tries to connect to ServerB, the SSL connection cannot be established.
> I believe this has to do with the underlying socket factory that is being used. This is crucial, since I need to use the default socket factory managed by webstart that automatically prompts for certificate issues and allows for automatic use of client certificates.
> Theory
> ----------------
> Terminology:
> javax.SSLSocketFactory = javax.net.ssl.SSLSocketFactory
> apache.SSLSocketFactory = org.apache.http.conn.ssl.SSLSocketFactory
> I am not exactly sure what is happening, but I have a theory. In my theory, the crux of the problem is that the DEFAULT apache.SSLSocketFactory is set in the static initializer of the apache.SSLSocketFactory class. In the first scenario above, webstart creates a new javax.SSLSocketFactory for the jar download, and makes this the default. This happens before the apache.SSLSocketFactory class is loaded, and, therefore, before the static initializer is executed. In the second scenario, this happens in the other order and the javax.SSLSocketFactory wrapped by the apache.SSLSocketFactory is not the one used by webstart
> I need to ensure that the javax.SSLSocketFactory is initialized (and replaced) first, and then create an apache.SSLSocketFactory to wrap this. The apache.SSLSocketFactory does have a wrapping construtor, but it is the private no-argument constructor. If this were public in some manner, I could create my apache.SSLSocketFactory after I was sure that the HttpsURLConnection default socket factory was the one I needed.
> Theory Corroborated
> --------------------
> I downloaded the httpclient 4.01 source (the version we are currently using), changed the no-arg constructor to be public, and used it to create a new apache.SSLSocketFactory after I initialized the HttpsURLConnection. This did indeed solve the problem. Perhaps there is more going on here than I realize, but it was not complicated and it worked.
> Another far easier work-around would be to do something like this:
> Constructor<SSLSocketFactory> con = SSLSocketFactory.class.getConstructor((Class<?>[]) null);
> con.setAccessible(true);
> fact = con.newInstance((Object[])null);
> RFE
> -------------
> Make the no-arg constructor public or provide access to it though another method
> I don't really see a down-side to making the no-arg constructor public. However, if this needs to be private to prevent certain types of subclassing, a static method could be added to create an apache.SSLSocketFactory that wraps the default javax.SSLSocketFactory. If the constructor is private just for historical reasons, than it may be easier to just make it public.
> If making the constructor public is undesirable for some reason, here is a recommendation for a change with minimal impact on the API and existing clients:
> Add method createSocketFactory(), as:
> public static SSLSocketFactory createSocketFactory() {
> return new SSLSocketFactory();
> }
> This will:
> 1) Solve the problem
> 2) Preserve backwards compatibility
> 3) Encourage the new semantics
> 4) Ensure that any protections afforded by the private SSLSocketFactory constructor are still in place
> In any case, after this change I think it is a good idea to deprecate the getSocketFactory() method. I would suspect that this method is not accessed frequently, so there is no real reason to optimize it in this way. I am also not sure if encouraging the use of a mutable* global shared socket factory is a good idea. If people want to use a particular socket factory, they should just create a new one, configure it how they want, and then keep it around to reuse as appropriate...without being in danger of another part of the application configuring it differently.
> * It seems to be mutable only through a single deprecated method, however.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Commented: (HTTPCLIENT-1059) Allow for the on-demand
creation of a new SSLSocketFactory that wraps the
HttpsURLConnection.getDefaultSSLSocketFactory()
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12997986#comment-12997986 ]
Oleg Kalnichevski commented on HTTPCLIENT-1059:
-----------------------------------------------
A diff file (or a patch in Apache lingo) would be the easiest way to communicate the changes you are proposing.
Oleg
> Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1059
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1059
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient
> Affects Versions: 3.1 Final, 4.0.3, 4.1 Final
> Environment: Applications using webstart
> Reporter: Mark Claassen
> Labels: HttpsURLConnection, SSLSocketFactory, ssl, webstart
> Fix For: Future
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I have been using HttpClient for a while now with success. However, I have recently encountering some problems which I think have an easy solution, although it is not accessible to me through the current API.
> Situation (my test enviroment):
> ServerA:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Only accepts non-SSL connections
> ServerB:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Contains a servlet
> * Only accepts SSL connections
> If I connect to serverB (via webstart) to download the jars, my app connects to the servlet on ServerB and everything is fine.
> However, if I connect to ServerA (via webstart) and then the app tries to connect to ServerB, the SSL connection cannot be established.
> I believe this has to do with the underlying socket factory that is being used. This is crucial, since I need to use the default socket factory managed by webstart that automatically prompts for certificate issues and allows for automatic use of client certificates.
> Theory
> ----------------
> Terminology:
> javax.SSLSocketFactory = javax.net.ssl.SSLSocketFactory
> apache.SSLSocketFactory = org.apache.http.conn.ssl.SSLSocketFactory
> I am not exactly sure what is happening, but I have a theory. In my theory, the crux of the problem is that the DEFAULT apache.SSLSocketFactory is set in the static initializer of the apache.SSLSocketFactory class. In the first scenario above, webstart creates a new javax.SSLSocketFactory for the jar download, and makes this the default. This happens before the apache.SSLSocketFactory class is loaded, and, therefore, before the static initializer is executed. In the second scenario, this happens in the other order and the javax.SSLSocketFactory wrapped by the apache.SSLSocketFactory is not the one used by webstart
> I need to ensure that the javax.SSLSocketFactory is initialized (and replaced) first, and then create an apache.SSLSocketFactory to wrap this. The apache.SSLSocketFactory does have a wrapping construtor, but it is the private no-argument constructor. If this were public in some manner, I could create my apache.SSLSocketFactory after I was sure that the HttpsURLConnection default socket factory was the one I needed.
> Theory Corroborated
> --------------------
> I downloaded the httpclient 4.01 source (the version we are currently using), changed the no-arg constructor to be public, and used it to create a new apache.SSLSocketFactory after I initialized the HttpsURLConnection. This did indeed solve the problem. Perhaps there is more going on here than I realize, but it was not complicated and it worked.
> Another far easier work-around would be to do something like this:
> Constructor<SSLSocketFactory> con = SSLSocketFactory.class.getConstructor((Class<?>[]) null);
> con.setAccessible(true);
> fact = con.newInstance((Object[])null);
> RFE
> -------------
> Make the no-arg constructor public or provide access to it though another method
> I don't really see a down-side to making the no-arg constructor public. However, if this needs to be private to prevent certain types of subclassing, a static method could be added to create an apache.SSLSocketFactory that wraps the default javax.SSLSocketFactory. If the constructor is private just for historical reasons, than it may be easier to just make it public.
> If making the constructor public is undesirable for some reason, here is a recommendation for a change with minimal impact on the API and existing clients:
> Add method createSocketFactory(), as:
> public static SSLSocketFactory createSocketFactory() {
> return new SSLSocketFactory();
> }
> This will:
> 1) Solve the problem
> 2) Preserve backwards compatibility
> 3) Encourage the new semantics
> 4) Ensure that any protections afforded by the private SSLSocketFactory constructor are still in place
> In any case, after this change I think it is a good idea to deprecate the getSocketFactory() method. I would suspect that this method is not accessed frequently, so there is no real reason to optimize it in this way. I am also not sure if encouraging the use of a mutable* global shared socket factory is a good idea. If people want to use a particular socket factory, they should just create a new one, configure it how they want, and then keep it around to reuse as appropriate...without being in danger of another part of the application configuring it differently.
> * It seems to be mutable only through a single deprecated method, however.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org
[jira] Resolved: (HTTPCLIENT-1059) Allow for the on-demand creation
of a new SSLSocketFactory that wraps the
HttpsURLConnection.getDefaultSSLSocketFactory()
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1059.
-------------------------------------------
Resolution: Won't Fix
Fix Version/s: (was: Future)
Mark,
Please re-open the issue when you are ready to contribute a patch.
Oleg
> Allow for the on-demand creation of a new SSLSocketFactory that wraps the HttpsURLConnection.getDefaultSSLSocketFactory()
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1059
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1059
> Project: HttpComponents HttpClient
> Issue Type: New Feature
> Components: HttpClient
> Affects Versions: 3.1 Final, 4.0.3, 4.1 Final
> Environment: Applications using webstart
> Reporter: Mark Claassen
> Labels: HttpsURLConnection, SSLSocketFactory, ssl, webstart
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> I have been using HttpClient for a while now with success. However, I have recently encountering some problems which I think have an easy solution, although it is not accessible to me through the current API.
> Situation (my test enviroment):
> ServerA:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Only accepts non-SSL connections
> ServerB:
> * Runs Tomcat 6
> * Contains jar files that are downloaded via webstart
> * Contains a servlet
> * Only accepts SSL connections
> If I connect to serverB (via webstart) to download the jars, my app connects to the servlet on ServerB and everything is fine.
> However, if I connect to ServerA (via webstart) and then the app tries to connect to ServerB, the SSL connection cannot be established.
> I believe this has to do with the underlying socket factory that is being used. This is crucial, since I need to use the default socket factory managed by webstart that automatically prompts for certificate issues and allows for automatic use of client certificates.
> Theory
> ----------------
> Terminology:
> javax.SSLSocketFactory = javax.net.ssl.SSLSocketFactory
> apache.SSLSocketFactory = org.apache.http.conn.ssl.SSLSocketFactory
> I am not exactly sure what is happening, but I have a theory. In my theory, the crux of the problem is that the DEFAULT apache.SSLSocketFactory is set in the static initializer of the apache.SSLSocketFactory class. In the first scenario above, webstart creates a new javax.SSLSocketFactory for the jar download, and makes this the default. This happens before the apache.SSLSocketFactory class is loaded, and, therefore, before the static initializer is executed. In the second scenario, this happens in the other order and the javax.SSLSocketFactory wrapped by the apache.SSLSocketFactory is not the one used by webstart
> I need to ensure that the javax.SSLSocketFactory is initialized (and replaced) first, and then create an apache.SSLSocketFactory to wrap this. The apache.SSLSocketFactory does have a wrapping construtor, but it is the private no-argument constructor. If this were public in some manner, I could create my apache.SSLSocketFactory after I was sure that the HttpsURLConnection default socket factory was the one I needed.
> Theory Corroborated
> --------------------
> I downloaded the httpclient 4.01 source (the version we are currently using), changed the no-arg constructor to be public, and used it to create a new apache.SSLSocketFactory after I initialized the HttpsURLConnection. This did indeed solve the problem. Perhaps there is more going on here than I realize, but it was not complicated and it worked.
> Another far easier work-around would be to do something like this:
> Constructor<SSLSocketFactory> con = SSLSocketFactory.class.getConstructor((Class<?>[]) null);
> con.setAccessible(true);
> fact = con.newInstance((Object[])null);
> RFE
> -------------
> Make the no-arg constructor public or provide access to it though another method
> I don't really see a down-side to making the no-arg constructor public. However, if this needs to be private to prevent certain types of subclassing, a static method could be added to create an apache.SSLSocketFactory that wraps the default javax.SSLSocketFactory. If the constructor is private just for historical reasons, than it may be easier to just make it public.
> If making the constructor public is undesirable for some reason, here is a recommendation for a change with minimal impact on the API and existing clients:
> Add method createSocketFactory(), as:
> public static SSLSocketFactory createSocketFactory() {
> return new SSLSocketFactory();
> }
> This will:
> 1) Solve the problem
> 2) Preserve backwards compatibility
> 3) Encourage the new semantics
> 4) Ensure that any protections afforded by the private SSLSocketFactory constructor are still in place
> In any case, after this change I think it is a good idea to deprecate the getSocketFactory() method. I would suspect that this method is not accessed frequently, so there is no real reason to optimize it in this way. I am also not sure if encouraging the use of a mutable* global shared socket factory is a good idea. If people want to use a particular socket factory, they should just create a new one, configure it how they want, and then keep it around to reuse as appropriate...without being in danger of another part of the application configuring it differently.
> * It seems to be mutable only through a single deprecated method, however.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org