You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Stojce Dimski (JIRA)" <ji...@apache.org> on 2007/11/06 11:35:51 UTC
[jira] Created: (HTTPCORE-129) Immutable request/response
Immutable request/response
--------------------------
Key: HTTPCORE-129
URL: https://issues.apache.org/jira/browse/HTTPCORE-129
Project: HttpComponents Core
Issue Type: Improvement
Components: HttpCore
Affects Versions: 4.0-beta1
Reporter: Stojce Dimski
Priority: Minor
There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
Is there some possibility to have e immutable request/response objects as in:
https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Resolved: (HTTPCORE-129) Immutable request/response
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCORE-129.
----------------------------------------
Resolution: Won't Fix
Stojce,
I am closing this issue as WONTFIX for now as no one seems interested in working on this improvement. Feel free to re-open it if you intend to submit a patch at some point. By the way HttpCore NIO is now Java 1.5 based as you wanted. Feedback would be very welcome ;-)
Oleg
> Immutable request/response
> --------------------------
>
> Key: HTTPCORE-129
> URL: https://issues.apache.org/jira/browse/HTTPCORE-129
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-beta1
> Reporter: Stojce Dimski
> Priority: Minor
>
> There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
> With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
> Is there some possibility to have e immutable request/response objects as in:
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-129) Immutable request/response
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540416 ]
Oleg Kalnichevski commented on HTTPCORE-129:
--------------------------------------------
Stojce
Odi is right. We decided to do away with immutable / mutable message interfaces because, while being very nice from the conceptual standpoint, the use of immutable interfaces led to ugly downcasts all over the place
http://marc.info/?l=httpclient-commons-dev&w=2&r=1&s=mutability+and+immutability&q=b
We might still turn things around and leave the default interfaces mutable but in additional provide their immutable counterparts for those cases where message immutability can be useful
HttpMessage extends HttpImmutableMessage
Opinions?
Oleg
> Immutable request/response
> --------------------------
>
> Key: HTTPCORE-129
> URL: https://issues.apache.org/jira/browse/HTTPCORE-129
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-beta1
> Reporter: Stojce Dimski
> Priority: Minor
>
> There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
> With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
> Is there some possibility to have e immutable request/response objects as in:
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-129) Immutable request/response
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540574 ]
Ortwin Glück commented on HTTPCORE-129:
---------------------------------------
Yes, it may be hard to guarantee read-only access on composite objects if you don't want to copy in getters/setters. For the Iterator at least there is the Enumeration read-only alternative.
> Immutable request/response
> --------------------------
>
> Key: HTTPCORE-129
> URL: https://issues.apache.org/jira/browse/HTTPCORE-129
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-beta1
> Reporter: Stojce Dimski
> Priority: Minor
>
> There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
> With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
> Is there some possibility to have e immutable request/response objects as in:
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-129) Immutable request/response
Posted by "Oleg Kalnichevski (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12541280 ]
Oleg Kalnichevski commented on HTTPCORE-129:
--------------------------------------------
Stojce,
HTTP messages in HttpCore are merely value objects. They contain no processing logic of what so ever that can mutate their state in unexpected ways. Therefore I personally do not see a lot of value in making them implement some sort of a read-only interface. Odi and Roland seem to agree. One would be much better off wrapping low level HttpMessage objects with some domain specific protocol object (such as HttpServletRequest) which could be read-only if so is desired.
Anyways, if you feel strongly about go ahead and put together a patch.
Oleg
> Immutable request/response
> --------------------------
>
> Key: HTTPCORE-129
> URL: https://issues.apache.org/jira/browse/HTTPCORE-129
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-beta1
> Reporter: Stojce Dimski
> Priority: Minor
>
> There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
> With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
> Is there some possibility to have e immutable request/response objects as in:
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-129) Immutable request/response
Posted by "Ortwin Glück (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540405 ]
Ortwin Glück commented on HTTPCORE-129:
---------------------------------------
As far as I remember it was a conscious design decision to do away with read-only interfaces (initial drafts of the API had that). It just causes painful type casts all over the place. Of course we could add the interfaces and just never use them internally. So the caller may use them at his descretion.
> Immutable request/response
> --------------------------
>
> Key: HTTPCORE-129
> URL: https://issues.apache.org/jira/browse/HTTPCORE-129
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-beta1
> Reporter: Stojce Dimski
> Priority: Minor
>
> There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
> With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
> Is there some possibility to have e immutable request/response objects as in:
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
[jira] Commented: (HTTPCORE-129) Immutable request/response
Posted by "Roland Weber (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HTTPCORE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12540534 ]
Roland Weber commented on HTTPCORE-129:
---------------------------------------
I'm not a big fan of the idea, though it might actually work since the referenced interfaces Header, RequestLine and StatusLine are read-only interfaces. But you have to omit the headerIterator() methods from the immutable message, to avoid message.headerIterator().remove();
Immutability ends with the entity, of course.
If you want to make this change, I have no objections.
cheers,
Roland
> Immutable request/response
> --------------------------
>
> Key: HTTPCORE-129
> URL: https://issues.apache.org/jira/browse/HTTPCORE-129
> Project: HttpComponents Core
> Issue Type: Improvement
> Components: HttpCore
> Affects Versions: 4.0-beta1
> Reporter: Stojce Dimski
> Priority: Minor
>
> There are many cases where user would just 'consume' response and would not have to modify nothing es. received response...
> With 2 interfaces and guideline to use a immutable version for polymorphic variables compiler would catch any error pretty soon...
> Is there some possibility to have e immutable request/response objects as in:
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/HttpMessage.java
> https://svn.safehaus.org/repos/asyncweb/trunk/core/src/main/java/org/safehaus/asyncweb/common/MutableHttpMessage.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org