Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.0.2
-
Fix Version/s: 2.1.1
-
Component/s: Modules: CXF
-
Labels:
-
User impact:High
-
Effort points:0.5
-
Similar Issues:
MULE-3500Upgrade to CXF 2.1.1MULE-1821Upgrade Jetty versionMULE-1525A Single Jetty HTTP/Rest Connector does not support multiple endpoints
MULE-4311 Defining a cxf:jetty// input endpoint results in the wsdl service url to be jetty:// and not http://MULE-5612NPE on initialise when using jetty-ssl with CXF jaxws-serviceMULE-3525Move the servlet/jetty support to their own moduleMULE-4684remove the Jetty endpoint hack in the AbstractEndpointBuilder
MULE-4064 transport archetype does not provide option to not extend any existing transportMULE-2850Patch for broken CXF at revision 10130 (branches/mule-2.x/transports/cxf/)MULE-4715Re-test transport hot deployment with CXF
Description
As a user, I can configure CXF to use the Jetty Transport
Acceptance Criteria
- Can configure CXF to use Jetty and is documented
Notes:
in New Mule Performance Benchmark( http://netzooid.com/blog/2008/07/21/new-mule-performance-benchmark-yup-we-come-out-on-top/ ), daniel say that
jetty transport is much better than http transport on tcp transport. it's true.
when we run loadtest of cxf transport over pure http transport, there are so many problems.
how to use jetty transport instead http transport when using cxf?
Dan wrote working unit test for this last week and it passed (only in IDE)
Needs get ut passing and some documentation
estimate: 0.5