|
|
| Created: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 13:17:50 |
AbstractHttpProcessor is not really abstract
--------------------------------------------
Key: HTTPCORE-13
URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
Project: HttpComponents Core
Issue Type: Improvement
Components: HttpCore
Affects Versions: 4.0-alpha3
Reporter: Roland Weber
Assigned To: Roland Weber
Priority: Minor
AbstractHttpProcessor is declared abstract though it does
not have any abstract method. This artificially restricts
use of the base class functionality to subclassing and
prohibits use by reference. That is one of the reasons why
HttpAsync has an ugly AsyncHttpProcessor class.
Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribe jakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Updated: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 13:23:50 |
[ http://issues.apache.org/jira/browse/HTTPCORE-13?page=a
ll ]
Roland Weber updated HTTPCORE-13:
---------------------------------
Attachment: 2k6-09-25-core-proc-1.txt
Take 1. Idea:
- define an interface for processing requests and responses
- turn AbstractHttpProcessor into DefaultHttpProcessor, make
processing methods public
- move default implementation to an implementation package
- HttpRequestExecutor and HttpService can no longer derive
from DefaultHttpProcessor,
since it is in an implementation package
Observation: HttpService is in an API package but imports
and instantiates two implementation classes.
Maybe we should reconsider the whole protocol package with
respect to API vs. implementation.
Please let me know what you think.
cheers,
Roland
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 14:02:50 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437565 ]
Oleg Kalnichevski commented on HTTPCORE-13:
-------------------------------------------
> - define an interface for processing requests and
responses
> - turn AbstractHttpProcessor into DefaultHttpProcessor,
make processing methods public
> - move default implementation to an implementation
package
> - HttpRequestExecutor and HttpService can no longer
derive from DefaultHttpProcessor,
> since it is in an implementation package
Makes sense. Wouldn 't HttpInterceptorChain be a better
name for this interface, though?
> Observation: HttpService is in an API package but
imports and instantiates two implementation classes.
> Maybe we should reconsider the whole protocol package
with respect to API vs. implementation.
You are right. This needs to be fixed
Oleg
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 16:26:50 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437598 ]
Roland Weber commented on HTTPCORE-13:
--------------------------------------
Hi Oleg,
> Wouldn 't HttpInterceptorChain be a better name for
this interface, though?
The interface in the patch makes no reference to
interceptors except in the JavaDoc.
If we include methods to add/remove interceptors to the
interface, I agree.
Right now, those methods are only in the implementation
class.
I think we'll have more of them in the future (like
index-based ones),
and I am reluctant to add the full selection to the
interface.
Read-only is enough for both request executor and service.
cheers,
Roland
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 17:38:50 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437618 ]
Oleg Kalnichevski commented on HTTPCORE-13:
-------------------------------------------
Fair enough. Please go ahead and commit the patch
Oleg
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 17:56:51 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437623 ]
Roland Weber commented on HTTPCORE-13:
--------------------------------------
take 1 committed with minor modifications to JavaDocs
I also fixed HttpAsync so that it compiles again. The async
fix is minimal and ugly. Things will have to be straightened
out later by eliminating AsyncHttpProcessor altogether. The
remaining functionality used from HttpRequestExecutor can be
provided in AbstractHttpDispatcher instead.
cheers,
Roland
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-25 20:12:50 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437664 ]
Oleg Kalnichevski commented on HTTPCORE-13:
-------------------------------------------
Roland,
I still somehow can't help feeling that HttpProcessor is
not a very appropriate name for this interface. Would the
following changes be okay with you?
Rename: HttpProcessor -> HttpProtocolHandler
Rename: DefaultHttpProcessor ->
o.a.http.protocol.BasicHttpProtocolHandler
Add: class o.a.http.protocol.HttpClientProtocolHandler
extends o.a.http.protocol.BasicHttpProtocolHandler {
public HttpClientProtocolHandler() {
super();
addInterceptor(new RequestContent());
addInterceptor(new RequestTargetHost());
addInterceptor(new RequestConnControl());
addInterceptor(new RequestUserAgent());
addInterceptor(new RequestExpectContinue());
}
}
Add: class o.a.http.protocol.HttpServerProtocolHandler
extends o.a.http.protocol.BasicHttpProtocolHandler {
public HttpClientProtocolHandler() {
super();
addInterceptor(new ResponseDate());
addInterceptor(new ResponseServer());
addInterceptor(new ResponseContent());
addInterceptor(new ResponseConnControl());
}
}
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-26 18:47:54 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437906 ]
Roland Weber commented on HTTPCORE-13:
--------------------------------------
Hi Oleg,
I kind of feel that HttpProtocolHandler does not give the
slightest indication what the class is supposed to do.
I liked the HttpInterceptorChain suggestion better. When I
worked on the patch I also considered HttpMessageProcessor.
HTTP protocol handling is much more than just setting up or
interpreting a few headers. Of course,
processing is also a very generic term. Some clicks on
WordNet (http://wordne
t.princeton.edu/perl/webwn)
lead me to "shape" or "mould" as
alternatives to indicate that the purpose is to bring a
message into a
particular form suitable for the following step.
HttpMessageShaper? HttpMessageSculptor? 
HttpMessageFilter is probably misleading.
cheers,
Roland
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-26 19:05:50 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437910 ]
Oleg Kalnichevski commented on HTTPCORE-13:
-------------------------------------------
All right. As always we agree to disagree. Can we at the
very least get rid of the o.a.http.impl.protocol package? In
my opinion it makes sense to keep the BasicHttpProcessor
class as a part of the public API.
Oleg
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|
| Commented: (HTTPCORE-13)
AbstractHttpProcessor is not really
abstract |
|
2006-09-26 19:22:59 |
[ http://issues.apache.org/jira/brow
se/HTTPCORE-13?page=comments#action_12437918 ]
Roland Weber commented on HTTPCORE-13:
--------------------------------------
Hi Oleg,
no problem. You can also change HttpRequestExecutor and
HttpService back to subclassing, if you prefer that.
I only changed them to use a reference because I moved the
implementation to an impl package.
cheers,
Roland
> AbstractHttpProcessor is not really abstract
> --------------------------------------------
>
> Key: HTTPCORE-13
> URL: http
://issues.apache.org/jira/browse/HTTPCORE-13
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-alpha3
> Reporter: Roland Weber
> Assigned To: Roland Weber
> Priority: Minor
> Attachments: 2k6-09-25-core-proc-1.txt
>
>
> AbstractHttpProcessor is declared abstract though it
does not have any abstract method. This artificially
restricts use of the base class functionality to subclassing
and prohibits use by reference. That is one of the reasons
why HttpAsync has an ugly AsyncHttpProcessor class.
> Patch follows.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira
------------------------------------------------------------
---------
To unsubscribe, e-mail: httpclient-dev-unsubscribejakarta.apache.org
For additional commands, e-mail: httpclient-dev-helpjakarta.apache.org
|
|