Details
-
Type:
Patch submission
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 1.3.3
-
Fix Version/s: 2.0.0
-
Component/s: Transport: HTTP(S) / Jetty
-
Labels:None
-
Environment:
RedHat ES4, Mule 1.3.3, JVM 6
-
Includes test case?:no
-
Similar Issues:
MULE-5811Jetty SSL connector does not support the webapps elementMULE-5134When multiple connectors are specified dynamic endpoints errors.MULE-1188Jetty Rest endpoints don't workMULE-1765"Multiple connectors" error (when only a single connector present)MULE-3418VM Connector cannot be configured to use a single thread on a singleton component
MULE-4219 Quartz endpoint polling job does not process multiple filesMULE-3508MulticastingRouter needs a new feature to support the execution of multiple endpoints in orderMULE-1665Multiple connector configurations for same protocol confuses mule despite explicit references by name at endpointsMULE-2667CLONE -Multiple connector configurations for same protocol confuses mule despite explicit references by name at endpointsMULE-520And and Or filters on endpoints should support multiple filters not just 2
Description
The http/rest jetty transport opens its sockets on the receiver as opposed to the connector level. As such, a separate port binding is required for every endpoint, making it impossible to have 2 endpoints share the same port ie:
jetty:http://192.168.1.10:8082/endpoint1
jetty:http://192.168.1.10:8082/endpoint2
We need to expose a fairly large amount of endpoints and this wouldn't scale for us, so I patched the jetty/http transport as follows:
- I moved the connection code from JettyHttpMessageReceiver.java into JavaConnector.java.
- JettyConnector.java was modified to contain a Map of Server instances, keyed by host and port. When an endpoint is configured, it requests a Context from the Connector. If a Server is already in the Map for the endpoint's host and port, that Server instance is returned. If not, a new instance is created and put into the Map.
- Modified JettyHttpMessageReceiver.java to name its Servlet after the endpoint name (as opposed to "JettyReceiverServlet" or "MuleRESTReceiverServlet")
- The JettyHttpMessgeReceiver is pushed into the ServletContext keyed by the servlet name and appended with "Receiver"
- The Jetty Server is stopped (if running) and started again to pick up the new handler (probably a better way to do this)
- Modified JettyReceiverServlet to pull the receiver out of the context based on the Servlet name.
Here is the relevant thread from the user list:
http://www.nabble.com/multiple-http-jetty-endpoints-on-a-single-connector-tf3434293.html#a9574825
Successfully patched to 1.4.0 http provider module, passed all module tests. Thanks.