Mailing-List: contact cxf-issues-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Message-ID: <12252386.1174142529491.JavaMail.jira@brutus>
Date: Sat, 17 Mar 2007 07:42:09 -0700 (PDT)
From: "willem Jiang (JIRA)" <jira@apache.org>
To: cxf-issues@incubator.apache.org
Subject: [jira] Resolved: (CXF-343) Servlet transport should be refactored
 to share common logic with core HTTP transport instead of duplicating
In-Reply-To: <26676908.1167749247787.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

willem Jiang resolved CXF-343.
------------------------------

    Resolution: Fixed

Please see CXF-462.

> Servlet transport should be refactored to share common logic with core HTTP transport instead of duplicating
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: CXF-343
>                 URL: https://issues.apache.org/jira/browse/CXF-343
>             Project: CXF
>          Issue Type: Improvement
>          Components: Transports
>    Affects Versions: 2.0-RC
>            Reporter: Eoghan Glynn
>         Assigned To: willem Jiang
>             Fix For: 2.0-RC
>
>
> The ServletDestination code was duplicated from the core HTTP transport (i.e. copied from the {Abstract|Jetty}HTTPDestination classes), and was not kept up to date as the core HTTP code evolved. So not only does it needlessly duplicate common code (e.g. the header manipulation logic), it is also missing a bunch of stuff that was added after it was forked, such as setting the CONTENT_TYPE or BASE_PATH properties on the incoming message.
> Also the servlet transport is an incomplete copy, in the sense that it uses a null ConduitInitiator and thus cannot possibly participate in a decoupled MEP, and doesn't seem to take the HTTPDestinationConfigBean into account at all.
> Clearly it would have been better to factor out the common HTTP logic into a set of shared abstract base classes to avoid these issues. That way we wouldn't have some functionality just arbitrarily missing from one HTTP transport, or mods/fixes applied to one but not the other. Each additional HTTP Destination implementation should only be concerned with the particulars of the HTTP engine its based on, say the differences between the Jetty HTTPRequest versus the HttpServletRequest provided by the servlet API.
> The sharing of common logic between the core HTTP and servlet transport would be further facilitated if the servlet code was moved out of the JAX-Ws module into the rt-transports-http module - as per issue CXF-342.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.