JERSEY-19
JERSEY-20
changed jersey exceptionMapper and contextResolver signatures to accept multiple elements.
Added test case for
MULE-6973, jersey:resources component doesn't register multiple jersey:context-resolver
MULE-6972
jersey:resources component doesn't register multiple exception mappers
(cherry picked from commit 79a8552)
Added test case for
MULE-6973, jersey:resources component doesn't register multiple jersey:context-resolver
MULE-6972
jersey:resources component doesn't register multiple exception mappers
(cherry picked from commit 79a8552)
Added test case for
MULE-6973, jersey:resources component doesn't register multiple jersey:context-resolver
MULE-6972
jersey:resources component doesn't register multiple exception mappers
Added config option to set the number of acceptor threads used by Jetty. Acceptor threads are those threads dedicated to accepting incoming connections. Increasing the number of acceptor threads can increase the throughput of a running system.

Changes were applied to JettyHttpConnector, JettyHttpsConnector and related configuration.

Functional tests are written to verify the configuration options are base down into the connector. Tests verify that acceptor threads are increased when accessing the application defined connector, and when accessing the connector used by the endpoint.
Added config option to set the number of acceptor threads used by Jetty. Acceptor threads are those threads dedicated to accepting incoming connections. Increasing the number of acceptor threads can increase the throughput of a running system
Broke up tests and test config so that each test defines only a single jetty connector to ensure the number of cumulative acceptor threads matches the (expected) configured value. combining multiple tests, or more specifically, multiple connectors into a single test config has the affect of producing a combined number acceptor threads across all tests.
Added test assertion method to verify the number of running acceptor threads matching the (expected) configured value.
Added some more comments in each test class on its purpose.
Changed comment in XSDs to match pattern I've seen used elsewhere.
added test of sending a request to and validating the response from jetty http/https endpoints
MULE-6993: ClassCast exception when using cxf:proxy-service and validationEnabled, and the request contains a CDATA field.
MULE-6990: OOM exception using foreach

avoid firing MP notifications for the builtin filter
(cherry picked from commit 8efdf608ea07aaf494236e33948aaeb37d899717)
MULE-6995: DynamicOutboundEndpoint does not use the connector's service overrides
EE-3372: Fixing bug. Exception should be thrown if context IS NOT stopping
MULE-6901 bundle schedulers module into standalon distribution
Merge branch 'mule-3.x' of https://github.com/mulesoft/mule into mule-3.x
  - now uses static imports for asserts/matchers
  - fix import order to match Mule coding style
  - fixed line ending after braces to match Mule coding style
  - specify the method visibility on methods in abstract class
  - removed unnecessary getConfigResources in abstract class
  - removed unused XSD imports in Spring config
apply MuleSoft coding style to my getter/setter in JettyHttpConnector
MULE-6986: http:static-resource-handler fails when request path is '/'
Merge pull request #29 from andresgregoire/dev/mule/bug/MULE-6986

MULE-6986: http:static-resource-handler fails when request path is '/'
MULE-6999: File Transport delays the processing of files when pollingFrequency attribute is uncomfortably narrow
MULE-6999: File Transport delays the processing of files when pollingFrequency attribute is uncomfortably narrow

_ Extracting test utils from AbstractFileFunctionalTestCase to FileTestUtils