You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Dan Creswell (JIRA)" <ji...@apache.org> on 2007/08/04 16:19:53 UTC
[jira] Created: (RIVER-187) (http) represent internal HTTP
utilities as connection manager implementation
(http) represent internal HTTP utilities as connection manager implementation
-----------------------------------------------------------------------------
Key: RIVER-187
URL: https://issues.apache.org/jira/browse/RIVER-187
Project: River
Issue Type: Improvement
Components: net_jini_jeri
Affects Versions: jtsk_2.0
Reporter: Dan Creswell
Priority: Trivial
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4856433
Recasting the com.sun.jini.jeri.internal.http.* utility classes as
(Server)ConnectionManager-like abstractions would allow the HTTPS and HTTP
transport provider implementations to be simplified, since presumably they
could then share most of their implementations with the SSL and TCP providers.
This would also reduce the number of similar but different abstractions
present internally within the JERI implementation. This could be done
by having the HTTP utility classes implement
the connection management interfaces in the
(implementation-internal) com.sun.jini.jeri.internal.connection package.Recasting the com.sun.jini.jeri.internal.http.* utility classes as
(Server)ConnectionManager-like abstractions would allow the HTTPS and HTTP
transport provider implementations to be simplified, since presumably they
could then share most of their implementations with the SSL and TCP providers.
This would also reduce the number of similar but different abstractions
present internally within the JERI implementation. This could be done
by having the HTTP utility classes implement
the connection management interfaces in the
(implementation-internal) com.sun.jini.jeri.internal.connection package.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.