[jira] [Closed] (HTTPCORE-455) The client does not check if the IO thread is alive
[
https://issues.apache.org/jira/browse/HTTPCORE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen closed HTTPCORE-455.
--
> The client does not check if the IO thread is alive
> ---
>
> Key: HTTPCORE-455
> URL: https://issues.apache.org/jira/browse/HTTPCORE-455
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Environment: Mac OSX, Java 8
>Reporter: Allen
> Fix For: 4.4.7, 5.0-alpha3
>
>
> When I developed with the latest HttpAsyncclient, it was hard for me to know
> whether the IO thread in BaseIOReactor was alive。 For example, if I throw an
> error in the callback，the IO thread will terminate,but the connecting thread
> will not check if the IO thread is alive,and will still add new channels to
> the dispatcher。
> The java code:
> CloseableHttpAsyncClient client = HttpAsyncClients.custom().build();
> client.start();
> HttpUriRequest getRequest = new HttpGet("www.google.com");
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> throw new StackOverflowError();
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> for(int i = 0 ; i < 100 ; i++){
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
>
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> }
> one of the IO threads is dead，but the java Error dose not be caught，and hte
> client will continue work and add new channels to the dispather, but the
> newChannel queue will be not be consumed, so I want to know is there any
> method to deal with this situation.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Reopened] (HTTPCORE-455) The client does not check if the IO thread is alive
[
https://issues.apache.org/jira/browse/HTTPCORE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Allen reopened HTTPCORE-455:
The latest version of httpcore-nio in maven repository is 4.4.6，the worker
thread catch exception but not throwable, and the connecting thread just
checked whether an exception happened。Once an unknown error happens, the worker
thread will stop but the connecting thread will never know,it seems that the
problem dose not be fixed in the 4.4.6。
> The client does not check if the IO thread is alive
> ---
>
> Key: HTTPCORE-455
> URL: https://issues.apache.org/jira/browse/HTTPCORE-455
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Environment: Mac OSX, Java 8
>Reporter: Allen
> Fix For: 4.4.7, 5.0-alpha3
>
>
> When I developed with the latest HttpAsyncclient, it was hard for me to know
> whether the IO thread in BaseIOReactor was alive。 For example, if I throw an
> error in the callback，the IO thread will terminate,but the connecting thread
> will not check if the IO thread is alive,and will still add new channels to
> the dispatcher。
> The java code:
> CloseableHttpAsyncClient client = HttpAsyncClients.custom().build();
> client.start();
> HttpUriRequest getRequest = new HttpGet("www.google.com");
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> throw new StackOverflowError();
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> for(int i = 0 ; i < 100 ; i++){
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
>
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> }
> one of the IO threads is dead，but the java Error dose not be caught，and hte
> client will continue work and add new channels to the dispather, but the
> newChannel queue will be not be consumed, so I want to know is there any
> method to deal with this situation.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Commented] (HTTPCORE-455) The client does not check if the IO thread is alive
[
https://issues.apache.org/jira/browse/HTTPCORE-455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15982272#comment-15982272
]
Allen commented on HTTPCORE-455:
The latest version of httpcore-nio in maven repository is 4.4.6，the worker
thread catch exception but not throwable, and the connecting thread just
checked whether an exception happened。Once an unknown error happens, the
worker thread will stop but the connecting thread will never know,it seems that
the problem dose not be fixed in the 4.4.6。
> The client does not check if the IO thread is alive
> ---
>
> Key: HTTPCORE-455
> URL: https://issues.apache.org/jira/browse/HTTPCORE-455
> Project: HttpComponents HttpCore
> Issue Type: Bug
> Environment: Mac OSX, Java 8
>Reporter: Allen
> Fix For: 4.4.7, 5.0-alpha3
>
>
> When I developed with the latest HttpAsyncclient, it was hard for me to know
> whether the IO thread in BaseIOReactor was alive。 For example, if I throw an
> error in the callback，the IO thread will terminate,but the connecting thread
> will not check if the IO thread is alive,and will still add new channels to
> the dispatcher。
> The java code:
> CloseableHttpAsyncClient client = HttpAsyncClients.custom().build();
> client.start();
> HttpUriRequest getRequest = new HttpGet("www.google.com");
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
> throw new StackOverflowError();
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> for(int i = 0 ; i < 100 ; i++){
> client.execute(getRequest, new FutureCallback() {
> @Override
> public void completed(HttpResponse result) {
>
> }
> @Override
> public void failed(Exception ex) {
> }
> @Override
> public void cancelled() {
> }
> });
> }
> one of the IO threads is dead，but the java Error dose not be caught，and hte
> client will continue work and add new channels to the dispather, but the
> newChannel queue will be not be consumed, so I want to know is there any
> method to deal with this situation.
> Thanks
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1727) org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager Does not account for context class loader
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Allen updated HTTPCLIENT-1727:
--
Fix Version/s: 4.5.3
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader
> --
>
> Key: HTTPCLIENT-1727
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1727
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
>Affects Versions: 4.4.1, 4.5, 4.5.1, 4.5.2
>Reporter: Charles Allen
> Fix For: 4.5.3
>
>
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader.
> This means that only ClientConnectionManager factories visible in
> AbstractHttpClient's classloader are loadable by AbstractHttpClient
> An example of a failure here is if httpclient and jets3t are loaded in
> different classloaders, where jets3t is in a child classloader of
> httpclient's classloader. In such a case httpclient classes will be visible
> to jets3t, but jets3t's classes will not be visible to httpclient so
> org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
> The proposed fix against the 4.5.x branch is as follows:
> {code}
> diff --git
> a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
>
> b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
> index 18a42d7..34c6e0f 100644
> ---
> a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
> +++
> b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
> @@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
> CloseableHttpClient {
> final String className = (String) params.getParameter(
> ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
> +final ClassLoader contextLoader =
> Thread.currentThread().getContextClassLoader();
> if (className != null) {
> try {
> -final Class clazz = Class.forName(className);
> +final Class clazz;
> +if(contextLoader != null) {
> +clazz = Class.forName(className, true, contextLoader);
> +} else {
> +clazz = Class.forName(className);
> +}
> factory = (ClientConnectionManagerFactory)
> clazz.newInstance();
> } catch (final ClassNotFoundException ex) {
> throw new IllegalStateException("Invalid class name: " +
> className);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Resolved] (HTTPCLIENT-1727) org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager Does not account for context class loader
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Allen resolved HTTPCLIENT-1727.
---
Resolution: Fixed
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader
> --
>
> Key: HTTPCLIENT-1727
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1727
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
>Affects Versions: 4.4.1, 4.5, 4.5.1, 4.5.2
>Reporter: Charles Allen
> Fix For: 4.5.3
>
>
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader.
> This means that only ClientConnectionManager factories visible in
> AbstractHttpClient's classloader are loadable by AbstractHttpClient
> An example of a failure here is if httpclient and jets3t are loaded in
> different classloaders, where jets3t is in a child classloader of
> httpclient's classloader. In such a case httpclient classes will be visible
> to jets3t, but jets3t's classes will not be visible to httpclient so
> org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
> The proposed fix against the 4.5.x branch is as follows:
> {code}
> diff --git
> a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
>
> b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
> index 18a42d7..34c6e0f 100644
> ---
> a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
> +++
> b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
> @@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
> CloseableHttpClient {
> final String className = (String) params.getParameter(
> ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
> +final ClassLoader contextLoader =
> Thread.currentThread().getContextClassLoader();
> if (className != null) {
> try {
> -final Class clazz = Class.forName(className);
> +final Class clazz;
> +if(contextLoader != null) {
> +clazz = Class.forName(className, true, contextLoader);
> +} else {
> +clazz = Class.forName(className);
> +}
> factory = (ClientConnectionManagerFactory)
> clazz.newInstance();
> } catch (final ClassNotFoundException ex) {
> throw new IllegalStateException("Invalid class name: " +
> className);
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Updated] (HTTPCLIENT-1727) org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager Does not account for context class loader
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Allen updated HTTPCLIENT-1727:
--
Description:
org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
Does not account for context class loader.
This means that only ClientConnectionManager factories visible in
AbstractHttpClient's classloader are loadable by AbstractHttpClient
An example of a failure here is if httpclient and jets3t are loaded in
different classloaders, where jets3t is in a child classloader of httpclient's
classloader. In such a case httpclient classes will be visible to jets3t, but
jets3t's classes will not be visible to httpclient so
org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
The proposed fix against the 4.5.x branch is as follows:
{code}
diff --git
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
index 18a42d7..34c6e0f 100644
---
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
+++
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
@@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
CloseableHttpClient {
final String className = (String) params.getParameter(
ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
+final ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
if (className != null) {
try {
-final Class clazz = Class.forName(className);
+final Class clazz;
+if(contextLoader != null) {
+clazz = Class.forName(className, true, contextLoader);
+} else {
+clazz = Class.forName(className);
+}
factory = (ClientConnectionManagerFactory) clazz.newInstance();
} catch (final ClassNotFoundException ex) {
throw new IllegalStateException("Invalid class name: " +
className);
{code}
was:
org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
Does not account for context class loader.
This means that only ClientConnectionManager factories visible in
AbstractHttpClient's classloader are loadable by AbstractHttpClient
An example of a failure here is if httpclient and jets3t are loaded in
different classloaders, where jets3t is in a child classloader of httpclient's
classloader. In such a case httpclient classes will be visible to jets3t, but
jets3t's classes will not be visible to httpclient so
org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
The proposed fix is as follows:
{code}
diff --git
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
index 18a42d7..34c6e0f 100644
---
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
+++
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
@@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
CloseableHttpClient {
final String className = (String) params.getParameter(
ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
+final ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
if (className != null) {
try {
-final Class clazz = Class.forName(className);
+final Class clazz;
+if(contextLoader != null) {
+clazz = Class.forName(className, true, contextLoader);
+} else {
+clazz = Class.forName(className);
+}
factory = (ClientConnectionManagerFactory) clazz.newInstance();
} catch (final ClassNotFoundException ex) {
throw new IllegalStateException("Invalid class name: " +
className);
{code}
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader
> --
>
> Key: HTTPCLIENT-1727
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1727
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
>Affects Versions: 4.4.1, 4.5, 4.5.1, 4.5.2
>Reporter: Charles Allen
>
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader.
> This means that only ClientConnectionManager facto
[jira] [Updated] (HTTPCLIENT-1727) org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager Does not account for context class loader
[
https://issues.apache.org/jira/browse/HTTPCLIENT-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charles Allen updated HTTPCLIENT-1727:
--
Description:
org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
Does not account for context class loader.
This means that only ClientConnectionManager factories visible in
AbstractHttpClient's classloader are loadable by AbstractHttpClient
An example of a failure here is if httpclient and jets3t are loaded in
different classloaders, where jets3t is in a child classloader of httpclient's
classloader. In such a case httpclient classes will be visible to jets3t, but
jets3t's classes will not be visible to httpclient so
org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
The proposed fix is as follows:
{code}
diff --git
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
index 18a42d7..34c6e0f 100644
---
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
+++
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
@@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
CloseableHttpClient {
final String className = (String) params.getParameter(
ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
+final ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
if (className != null) {
try {
-final Class clazz = Class.forName(className);
+final Class clazz;
+if(contextLoader != null) {
+clazz = Class.forName(className, true, contextLoader);
+} else {
+clazz = Class.forName(className);
+}
factory = (ClientConnectionManagerFactory) clazz.newInstance();
} catch (final ClassNotFoundException ex) {
throw new IllegalStateException("Invalid class name: " +
className);
{code}
was:
org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
Does not account for context class loader.
This means that only ClientConnectionManager factories visible in
AbstractHttpClient's classloader are loadable by AbstractHttpClient
An example of a failure here is if httpclient and jets3t are loaded in
different classloaders, where jets3t is in a child classloader of httpclient's
classloader. In such a case httpclient classes will be visible to jets3t, but
jets3t's classes will not be visible to httpclient so
org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
The proposed fix is as follows:
diff --git
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
index 18a42d7..34c6e0f 100644
---
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
+++
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
@@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
CloseableHttpClient {
final String className = (String) params.getParameter(
ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
+final ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
if (className != null) {
try {
-final Class clazz = Class.forName(className);
+final Class clazz;
+if(contextLoader != null) {
+clazz = Class.forName(className, true, contextLoader);
+} else {
+clazz = Class.forName(className);
+}
factory = (ClientConnectionManagerFactory) clazz.newInstance();
} catch (final ClassNotFoundException ex) {
throw new IllegalStateException("Invalid class name: " +
className);
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader
> --
>
> Key: HTTPCLIENT-1727
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1727
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
>Affects Versions: 4.4.1, 4.5, 4.5.1, 4.5.2
>Reporter: Charles Allen
>
> org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
> Does not account for context class loader.
> This means that only ClientConnectionManager factories visible in
> AbstractHttpClient'
[jira] [Created] (HTTPCLIENT-1727) org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager Does not account for context class loader
Charles Allen created HTTPCLIENT-1727:
-
Summary:
org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
Does not account for context class loader
Key: HTTPCLIENT-1727
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1727
Project: HttpComponents HttpClient
Issue Type: Bug
Components: HttpClient
Affects Versions: 4.5.2, 4.5.1, 4.5, 4.4.1
Reporter: Charles Allen
org.apache.http.impl.client.AbstractHttpClient#createClientConnectionManager
Does not account for context class loader.
This means that only ClientConnectionManager factories visible in
AbstractHttpClient's classloader are loadable by AbstractHttpClient
An example of a failure here is if httpclient and jets3t are loaded in
different classloaders, where jets3t is in a child classloader of httpclient's
classloader. In such a case httpclient classes will be visible to jets3t, but
jets3t's classes will not be visible to httpclient so
org.jets3t.service.utils.RestUtils$ConnManagerFactory will not be found.
The proposed fix is as follows:
diff --git
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
index 18a42d7..34c6e0f 100644
---
a/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
+++
b/httpclient/src/main/java-deprecated/org/apache/http/impl/client/AbstractHttpClient.java
@@ -327,9 +327,15 @@ public abstract class AbstractHttpClient extends
CloseableHttpClient {
final String className = (String) params.getParameter(
ClientPNames.CONNECTION_MANAGER_FACTORY_CLASS_NAME);
+final ClassLoader contextLoader =
Thread.currentThread().getContextClassLoader();
if (className != null) {
try {
-final Class clazz = Class.forName(className);
+final Class clazz;
+if(contextLoader != null) {
+clazz = Class.forName(className, true, contextLoader);
+} else {
+clazz = Class.forName(className);
+}
factory = (ClientConnectionManagerFactory) clazz.newInstance();
} catch (final ClassNotFoundException ex) {
throw new IllegalStateException("Invalid class name: " +
className);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
[jira] [Created] (HTTPCORE-259) inaccurate exception message at org.apache.http.protocol.ResponseContent.java line 60
inaccurate exception message at org.apache.http.protocol.ResponseContent.java
line 60
--
Key: HTTPCORE-259
URL: https://issues.apache.org/jira/browse/HTTPCORE-259
Project: HttpComponents HttpCore
Issue Type: Bug
Components: HttpCore
Affects Versions: 4.1
Reporter: Allen
Priority: Minor
/**/ public class ResponseContent
/**/ implements HttpResponseInterceptor
/**/ {
/**/ public void process(HttpResponse response, HttpContext context)
/**/ throws HttpException, IOException
/**/ {
/* 59 */ if (response == null) {
/* 60 */ throw new IllegalArgumentException("HTTP request may not be
null"); // "request" should be "response"
/**/ }
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
