Jetty — provides endpoints for consuming HTTP requests
The Jetty component provides HTTP-based endpoints for consuming HTTP requests. That is, the Jetty component behaves as a simple Web server. Jetty can also be used as a http client which mean you can also use it with Camel as a producer.
![]() | Important |
---|---|
Jetty is stream based, which means the input it receives is
submitted to Camel as a stream. That means you will only be able
to read the content of the stream once. If you find a situation where the message
body appears to be empty or you need to access the data multiple
times (eg: doing multicasting, or redelivery error handling) you
should use Stream Caching
or convert the message body to a |
The URI format for a Jetty endpoint is:
jetty:http(s)://hostname
[:port
][/resourceUri
][?options
]
You can append query options to the URI in the following format:
?option=value&option=value&...
Maven users will need to add the following dependency to their
pom.xml
for this component:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-jetty</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
Table 29, “Jetty options” lists the options for a Jetty endpoint.
Table 29. Jetty options
Name | Default | Description |
---|---|---|
sessionSupport
|
false
| Specifies whether to enable the session manager on the server side of Jetty. |
httpClient.XXX
|
null
| Configuration of Jetty's HttpClient. For example, setting
httpClient.idleTimeout=30000 sets the
idle timeout to 30 seconds. |
httpClient
|
null
| To use a shared
org.eclipse.jetty.client.HttpClient
for all producers created by this endpoint. This option
should only be used in special circumstances. |
httpClientMinThreads
|
null
| Camel 2.11:Producer only: To set a value for
minimum number of threads in HttpClient
thread pool. This setting override any setting configured on
component level. Notice that both a min and max size must be
configured. |
httpClientMaxThreads
|
null
| Camel 2.11:Producer only: To set a value for
maximum number of threads in HttpClient
thread pool. This setting override any setting configured on
component level. Notice that both a min and max size must be
configured. |
httpBindingRef
|
null
| Reference to an
org.apache.camel.component.http.HttpBinding
in the Registry.
HttpBinding can be used to customize
how a response should be written for the consumer. |
jettyHttpBindingRef
|
null
|
Camel 2.6.0+: Reference to
an
org.apache.camel.component.jetty.JettyHttpBinding
in the Registry.
JettyHttpBinding can be used to
customize how a response should be written for the producer.
|
matchOnUriPrefix
|
false
| Whether or not the CamelServlet should
try to find a target consumer by matching the URI prefix if
no exact match is found. See here How do I
let Jetty match wildcards. |
handlers
|
null
| Specifies a comma-delimited set of
org.mortbay.jetty.Handler instances
in your Registry (such as
your Spring ApplicationContext ). These
handlers are added to the Jetty servlet context (for
example, to add security). |
chunked
|
true
| Camel 2.2: If this option is false Jetty servlet will disable the HTTP streaming and set the content-length header on the response |
enableJmx
|
false
| Camel 2.3: If this option is true, Jetty JMX support will be enabled for this endpoint. See Jetty JMX support for more details. |
disableStreamCache
|
false
|
Camel 2.3: Determines whether the raw input stream from Jetty is cached (Camel reads the stream into an in-memory/overflow-to-file cache, Stream caching). By default, Camel caches the Jetty input stream so
that the stream can be read multiple times and
to ensure that Camel can retrieve all data from
the stream. In support of multiple stream reads,
Set this option to Note: If you use Jetty to bridge/proxy an endpoint, consider enabling this option to improve performance, when you do not need to read the message payload multiple times. |
throwException OnFailure
|
true
| Option to disable throwing the
HttpOperationFailedException
in case of failed responses from the remote server.
This allows you to get all responses regardles of
the HTTP status code. |
transferException
|
false
| Camel 2.6: If enabled and
an Exchange failed
processing on the consumer side, and if the caused Exception
was send back serialized in the response as a
application/x-java-serialized-object
content type. On the producer side the exception will be
deserialized and thrown as is, instead of the
HttpOperationFailedException . The
caused exception is required to be serialized. |
bridgeEndpoint
|
false
|
>Camel 2.1: If the option is true , HttpProducer will ignore the Exchange.HTTP_URI header, and use the endpoint's URI for request. You may also set the throwExceptionOnFailure to be false to let the HttpProducer send all the fault response back. Camel 2.3: If the option is true, HttpProducer and CamelServlet will skip the gzip processing if the content-encoding is "gzip". Also consider setting disableStreamCache to true to optimize when bridging. |
enableMultipart Filter
|
true
|
Camel 2.5: Whether Jetty
org.eclipse.jetty.servlets.MultiPartFilter
is enabled or not. You should set this value to
false when bridging endpoints, to
ensure multipart requests is proxied/bridged as well. |
multipartFilterRef
|
null
|
Camel 2.6: Allows using a
custom multipart filter. Note: setting
multipartFilterRef forces the value
of enableMultipartFilter to
true . |
FiltersRef
|
null
| Camel 2.9: Allows using a custom filters which is putted into a list and can be find in the Registry |
continuationTimeout
|
null
|
Camel 2.6: Allows to set a
timeout in millis when using Jetty as consumer (server). By default Jetty
uses 30000. You can use a value of <=
0 to never expire. If a timeout occurs then
the request will be expired and Jetty will return back a
http error 503 to the client. This option is only in use
when using Jetty with
the Asynchronous
Routing Engine. |
useContinuation
|
true
| Camel 2.6: Whether or not to use Jetty continuations for the Jetty Server. |
sslContext ParametersRef
|
null
|
Camel 2.8: Reference to a
org.apache.camel.util.jsse.SSLContextParameters
in the http://camel.apache.org/registry.html. This
reference overrides any configured SSLContextParameters at
the component level. See Using the JSSE Configuration Utility. |
traceEnabled
|
false
| Specifies whether to enable HTTP TRACE for this Jetty consumer. By default TRACE is turned off. |
headerFilter Strategy
|
null
| Camel 2.11: Reference to a
instance of
org.apache.camel.spi.HeaderFilterStrategy
in the Registry. It will be
used to apply the custom headerFilterStrategy on the new
create HttpJettyEndpoint. |
urlRewrite
|
null
| Camel 2.11:Producer only Refers to a custom
org.apache.camel.component.http.UrlRewrite
which allows you to rewrite urls when you bridge/proxy
endpoints. See more details at URLrewrite
and
How to use Camel as a HTTP proxy between a
client and server. |
responseBufferSize
|
null
| Camel 2.12: To use a custom
buffer size on the
javax.servlet.ServletResponse . |
Apache Camel uses the same message headers as the HTTP component.
It also uses the Exchange.HTTP_CHUNKED, CamelHttpChunked
header to turn on/off the
chunked encoding on the consumer.
Apache Camel also populates all
request.parameter
and request.headers
. For example, given a
client request with the URL http://myserver/myserver?orderid=123
, the
exchange will contain a header named orderid
with the value
123
.
Camel also populates all
request.parameter and request.headers. For example, given a client
request with the URL,
http://myserver/myserver?orderid=123
, the
exchange will contain a header named orderid
with
the value 123.
Starting with Camel 2.2.0, you can get the request.parameter from the message header not only from Get Method, but also other HTTP method.
The JettyHttpComponent
supports both consumer and producer
endpoints. You can also use the HTTP component for producing to other HTTP
endpoints. From Camel 2.2, it
also uses (Exchange.HTTP_CHUNKED,CamelHttpChunked) header to turn on
or turn off the chuched encoding on the camel-jetty consumer.
The JettyHttpComponent
provides the following options:
Name | Default | Description |
---|---|---|
enableJmx
|
false
| Camel 2.3: If this option is true, Jetty JMX support will be enabled for this endpoint. See Jetty JMX Support for more details. |
sslKeyPassword
|
null
| Consumer only: The password for the keystore when using SSL. |
sslPassword
|
null
| Consumer only: The password when using SSL. |
sslKeystore
|
null
| Consumer only: The path to the keystore. |
minThreads
|
null
| Camel 2.5 Consumer only: To set a value for minimum number of threads in server thread pool. |
maxThreads
|
null
| Camel 2.5 Consumer only: To set a value for maximum number of threads in server thread pool. |
threadPool
|
null
| Camel 2.5 Consumer only: To use a custom thread pool for the server. |
sslSocketConnectors
|
null
| Camel 2.3 Consumer only: A map which contains per port number specific SSL connectors. See section SSL support for more details. |
socketConnectors
|
null
|
Camel 2.5
Consumer only: A map which
contains per port number specific HTTP connectors. Uses the
same principle as sslSocketConnectors and
therefore see section SSL support for
more details. |
sslSocketConnectorProperties
|
null
| Camel 2.5 Consumer only. A map which contains general SSL connector properties. See section SSL support for more details. |
socketConnectorProperties
|
null
|
Camel 2.5
Consumer only. A map which
contains general HTTP connector properties. Uses the same
principle as sslSocketConnectorProperties
and therefore see section SSL support
for more details. |
httpClient
|
null
| Deprecated:Producer only: To use a custom
HttpClient with the jetty producer.
This option is removed from Camel 2.11 onwards, instead you
can set the option on the endpoint instead. |
httpClientMinThreads
|
null
| Producer only: To set a
value for minimum number of threads in
HttpClient thread pool. Notice that
both a min and max size must be configured. |
httpClientMaxThreads
|
null
| Producer only: To set a
value for maximum number of threads in
HttpClient thread pool. Notice that
both a min and max size must be configured. |
httpClientThreadPool
|
null
| Deprecated:Producer only: To use a custom thread pool for the client. This option is removed from Camel 2.11 onwards. |
sslContextParameters
|
null
| Camel 2.8: To configure a custom SSL/TLS configuration options at the component level. See Using the JSSE Configuration Utility for more details. |
requestBufferSize
|
null
| Camel 2.11.2: Allows to configure a custom value of the request buffer size on the Jetty connectors. |
requestHeaderSize
|
null
| Camel 2.11.2: Allows to configure a custom value of the request header size on the Jetty connectors. |
responseBufferSize
|
null
| Camel 2.11.2: Allows to configure a custom value of the response buffer size on the Jetty connectors. |
responseHeaderSize
|
null
| Camel 2.11.2: Allows to configure a custom value of the response header size on the Jetty connectors. |
The following is a basic example of how to send an HTTP request to an existing HTTP endpoint.
in Java DSL
from("direct:start").to("jetty://http://www.google.com");
or in Spring XML
<route> <from uri="direct:start"/> <to uri="jetty://http://www.google.com"/> <route>
In this sample we define a route that exposes a HTTP service at
http://localhost:8080/myapp/myservice
:
from("jetty:http://localhost:{{port}}/myapp/myservice").process(new MyBookService());
![]() | Usage of localhost |
---|---|
When you specify If you need to expose a Jetty endpoint on a specific network
interface, the numerical IP address of this interface should be
used as the host. If you need to expose a Jetty endpoint on all
network interfaces, the |
Our business logic is implemented in the
MyBookService
class, which accesses the HTTP
request contents and then returns a response. Note: The assert
call appears in
this example, because the code is part of an unit test.
public class MyBookService implements Processor { public void process(Exchange exchange) throws Exception { // just get the body as a string String body = exchange.getIn().getBody(String.class); // we have access to the HttpServletRequest here and we can grab it if we need it HttpServletRequest req = exchange.getIn().getBody(HttpServletRequest.class); assertNotNull(req); // for unit testing assertEquals("bookid=123", body); // send a html response exchange.getOut().setBody("<html><body>Book 123 is Camel in Action</body></html>"); } }
The following sample shows a content-based route that routes all
requests containing the URI parameter, one
, to
the endpoint, mock:one
, and all others to
mock:other
.
from("jetty:" + serverUri) .choice() .when().simple("${header.one}").to("mock:one") .otherwise() .to("mock:other");
So if a client sends the HTTP request, http://serverUri?one=hello
, the Jetty
component will copy the HTTP request parameter,
one
to the exchange's
in.header
. We can then use the
simple
language to route exchanges that
contain this header to a specific endpoint and all others to
another.
If we used a language more powerful than Simple, such as El or OGNL, we could also test for the parameter value and do routing based on the header value as well.
The session support option, sessionSupport
, can
be used to enable a HttpSession
object and access
the session object while processing the exchange. For example, the
following route enables sessions:
<route> <from uri="jetty:http://0.0.0.0/myapp/myservice/?sessionSupport=true"/> <processRef ref="myCode"/> <route>
The myCode
Processor can be instantiated by a
Spring bean
element:
<bean id="myCode"class="com.mycompany.MyCodeProcessor"/>
Where the processor implementation can access the
HttpSession
as follows:
public void process(Exchange exchange) throws Exception { HttpSession session = exchange.getIn(HttpMessage.class).getRequest().getSession(); ... }
As of Camel 2.8, the Jetty component supports SSL/TLS configuration through the Camel JSSE Configuration Utility. This utility greatly decreases the amount of component specific code you need to write and is configurable at the endpoint and component levels. The following examples demonstrate how to use the utility with the Jetty component.
KeyStoreParameters ksp = new KeyStoreParameters(); ksp.setResource("/users/home/server/keystore.jks"); ksp.setPassword("keystorePassword"); KeyManagersParameters kmp = new KeyManagersParameters(); kmp.setKeyStore(ksp); kmp.setKeyPassword("keyPassword"); SSLContextParameters scp = new SSLContextParameters(); scp.setKeyManagers(kmp); JettyComponent jettyComponent = getContext().getComponent("jetty", JettyComponent.class); jettyComponent.setSslContextParameters(scp);
... <camel:sslContextParameters id="sslContextParameters"> <camel:keyManagers keyPassword="keyPassword"> <camel:keyStore resource="/users/home/server/keystore.jks" password="keystorePassword"/> </camel:keyManagers> </camel:sslContextParameters>... ... <to uri="jetty:https://127.0.0.1/mail/?sslContextParametersRef=sslContextParameters"/> ...
Jetty provides SSL support out of the box. To enable Jetty to run
in SSL mode, simply format the URI with the
https://
prefix---for example:
<from uri="jetty:https://0.0.0.0/myapp/myservice/"/>
Jetty also needs to know where to load your keystore from and what passwords to use in order to load the correct SSL certificate. Set the following JVM System Properties:
until Camel 2.2
jetty.ssl.keystore
specifies the
location of the Java keystore file, which contains the Jetty
server's own X.509 certificate in a key
entry. A key entry stores the X.509
certificate (effectively, the public
key) and also its associated private
key.
jetty.ssl.password
the store password,
which is required to access the keystore file (this is the
same password that is supplied to the
keystore
command's
\-storepass
option).
jetty.ssl.keypassword
the key password,
which is used to access the certificate's key entry in the
keystore (this is the same password that is supplied to the
keystore
command's
\-keypass
option).
from Camel 2.3 onwards
org.eclipse.jetty.ssl.keystore
specifies the location of the Java keystore file, which
contains the Jetty server's own X.509 certificate in a
key entry. A key entry stores the
X.509 certificate (effectively, the public
key) and also its associated private
key.
org.eclipse.jetty.ssl.password
the
store password, which is required to access the keystore
file (this is the same password that is supplied to the
keystore
command's
\-storepass
option).
org.eclipse.jetty.ssl.keypassword
the
key password, which is used to access the certificate's key
entry in the keystore (this is the same password that is
supplied to the keystore
command's
\-keypass
option).
For details of how to configure SSL on a Jetty endpoint, read the following documentation at the Jetty Site: http://docs.codehaus.org/display/JETTY/How+to+configure+SSL
Some SSL properties aren't exposed directly by Camel, however Camel does expose the underlying SslSocketConnector, which will allow you to set properties like needClientAuth for mutual authentication requiring a client certificate or wantClientAuth for mutual authentication where a client doesn't need a certificate but can have one. There's a slight difference between the various Camel versions:
Up to Camel 2.2
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectors"> <map> <entry key="8043"> <bean class="org.mortbay.jetty.security.SslSocketConnector"> <property name="password"value="..."/> <property name="keyPassword"value="..."/> <property name="keystore"value="..."/> <property name="needClientAuth"value="..."/> <property name="truststore"value="..."/> </bean> </entry> </map> </property> </bean>
Camel 2.3, 2.4
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectors"> <map> <entry key="8043"> <bean class="org.eclipse.jetty.server.ssl.SslSocketConnector"> <property name="password"value="..."/> <property name="keyPassword"value="..."/> <property name="keystore"value="..."/> <property name="needClientAuth"value="..."/> <property name="truststore"value="..."/> </bean> </entry> </map> </property> </bean>
\*From Camel 2.5 we switch to use SslSelectChannelConnector *
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectors"> <map> <entry key="8043"> <bean class="org.eclipse.jetty.server.ssl.SslSelectChannelConnector"> <property name="password"value="..."/> <property name="keyPassword"value="..."/> <property name="keystore"value="..."/> <property name="needClientAuth"value="..."/> <property name="truststore"value="..."/> </bean> </entry> </map> </property> </bean>
The value you use as keys in the above map is the port you configure Jetty to listen on.
Available as of Camel 2.5
Instead of a per port number specific SSL socket connector (as shown above) you can now configure general properties which applies for all SSL socket connectors (which is not explicit configured as above with the port number as entry).
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="sslSocketConnectorProperties"> <map> <entry key="password"value="..."/> <entry key="keyPassword"value="..."/> <entry key="keystore"value="..."/> <entry key="needClientAuth"value="..."/> <entry key="truststore"value="..."/> </map> </property> </bean>
Jetty stores a reference to the certificate in the HttpServletRequest which you can access from code as follows:
HttpServletRequest req = exchange.getIn().getBody(HttpServletRequest.class); X509Certificate cert = (X509Certificate) req.getAttribute("javax.servlet.request.X509Certificate")
Available as of Camel 2.5
Instead of a per port number specific HTTP socket connector (as shown above) you can now configure general properties which applies for all HTTP socket connectors (which is not explicit configured as above with the port number as entry).
<bean id="jetty" class="org.apache.camel.component.jetty.JettyHttpComponent"> <property name="socketConnectorProperties"> <map> <entry key="acceptors" value="4"/> <entry key="maxIdleTime" value="300000"/> </map> </property> </bean>
The default behavior of HTTP status codes is defined by the
org.apache.camel.component.http.DefaultHttpBinding
class, which handles how a response is written and also sets the
HTTP status code.
If the exchange was processed successfully, the 200 HTTP status
code is returned. If the exchange failed with an exception, the 500
HTTP status code is returned, and the stacktrace is returned in the
body. If you want to specify which HTTP status code to return, set
the code in the HttpProducer.HTTP_RESPONSE_CODE
header of the OUT message.
By default, Camel uses the
org.apache.camel.component.http.DefaultHttpBinding
to handle how a response is written. If you like, you can customize
this behavior either by implementing your own
HttpBinding
class or by extending
DefaultHttpBinding
and overriding the
appropriate methods.
The following example shows how to customize the
DefaultHttpBinding
in order to change how
exceptions are returned:
public class MyHttpBinding extends DefaultHttpBinding { public MyHttpBinding(HttpEndpoint ep) { super(ep); } @Override public void doWriteExceptionResponse(Throwable exception, HttpServletResponse response) throws IOException { // we override the doWriteExceptionResponse as we only want to alter the binding how exceptions is // written back to the client. // we just return HTTP 200 so the client thinks its okay response.setStatus(200); // and we return this fixed text response.getWriter().write("Something went wrong but we dont care"); } }
We can then create an instance of our binding and register it in the Spring registry as follows:
<bean id="mybinding"class="com.mycompany.MyHttpBinding"/>
And then we can reference this binding when we define the route:
<route><from uri="jetty:http://0.0.0.0:8080/myapp/myservice?httpBindingRef=mybinding"/><to uri="bean:doSomething"/></route>
You can configure a list of Jetty handlers on the endpoint, which can be useful for enabling advanced Jetty security features. These handlers are configured in Spring XML as follows:
<-- Jetty Security handling --> <bean id="userRealm" class="org.mortbay.jetty.plus.jaas.JAASUserRealm"> <property name="name" value="tracker-users"/> <property name="loginModuleName" value="ldaploginmodule"/> </bean> <bean id="constraint" class="org.mortbay.jetty.security.Constraint"> <property name="name" value="BASIC"/> <property name="roles" value="tracker-users"/> <property name="authenticate" value="true"/> </bean> <bean id="constraintMapping" class="org.mortbay.jetty.security.ConstraintMapping"> <property name="constraint" ref="constraint"/> <property name="pathSpec" value="/*"/> </bean> <bean id="securityHandler" class="org.mortbay.jetty.security.SecurityHandler"> <property name="userRealm" ref="userRealm"/> <property name="constraintMappings" ref="constraintMapping"/> </bean>
And from Camel 2.3 onwards you can configure a list of Jetty handlers as follows:
<-- Jetty Security handling --> <bean id="constraint" class="org.eclipse.jetty.http.security.Constraint"> <property name="name" value="BASIC"/> <property name="roles" value="tracker-users"/> <property name="authenticate" value="true"/> </bean> <bean id="constraintMapping" class="org.eclipse.jetty.security.ConstraintMapping"> <property name="constraint" ref="constraint"/> <property name="pathSpec" value="/*"/> </bean> <bean id="securityHandler" class="org.eclipse.jetty.security.ConstraintSecurityHandler"> <property name="authenticator"> <bean class="org.eclipse.jetty.security.authentication.BasicAuthenticator"/> </property> <property name="constraintMappings"> <list> <ref bean="constraintMapping"/> </list> </property> </bean>
You can then define the endpoint as:
from("jetty:http://0.0.0.0:9080/myservice?handlers=securityHandler")
If you need more handlers, set the handlers
option equal to a comma-separated list of bean IDs.
You may want to return a custom reply message when something goes
wrong, instead of the default reply message Camel Jetty replies with. You could use
a custom HttpBinding
to be in control of the
message mapping, but often it may be easier to use Camel's Exception Clause to construct
the custom reply message. For example as show here, where we return
Dude something went wrong
with HTTP error
code 500:
from("jetty://http://localhost:{{port}}/myserver") // use onException to catch all exceptions and return a custom reply message .onException(Exception.class) .handled(true) // create a custom failure response .transform(constant("Dude something went wrong")) // we must remember to set error code 500 as handled(true) // otherwise would let Camel thing its a OK response (200) .setHeader(Exchange.HTTP_RESPONSE_CODE, constant(500)) .end() // now just force an exception immediately .throwException(new IllegalArgumentException("I cannot do this"));
From Camel 2.3.0, camel-jetty support to multipart form post out of box. The submitted form-data are mapped into the message header. Camel-jetty creates an attachment for each uploaded file. The file name is mapped to the name of the attachment. The content type is set as the content type of the attachment file name. You can find the example here.
// Set the jetty temp directory which store the file for multi part form // camel-jetty will clean up the file after it handled the request. // The option works rightly from Camel 2.4.0 getContext().getProperties().put("CamelJettyTempDir", "target"); from("jetty://http://localhost:{{port}}/test").process(new Processor() { public void process(Exchange exchange) throws Exception { Message in = exchange.getIn(); assertEquals("Get a wrong attachement size", 1, in.getAttachments().size()); // The file name is attachment id DataHandler data = in.getAttachment("NOTICE.txt"); assertNotNull("Should get the DataHandle NOTICE.txt", data); // This assert is wrong, but the correct content-type (application/octet-stream) // will not be returned until Jetty makes it available - currently the content-type // returned is just the default for FileDataHandler (for the implentation being used) //assertEquals("Get a wrong content type", "text/plain", data.getContentType()); assertEquals("Got the wrong name", "NOTICE.txt", data.getName()); assertTrue("We should get the data from the DataHandle", data.getDataSource() .getInputStream().available() > 0); // The other form date can be get from the message header exchange.getOut().setBody(in.getHeader("comment")); } });
From Camel 2.3.0, camel-jetty supports the enabling of Jetty's JMX capabilities at the component and endpoint level with the endpoint configuration taking priority. Note that JMX must be enabled within the Camel context in order to enable JMX support in this component as the component provides Jetty with a reference to the MBeanServer registered with the Camel context. Because the camel-jetty component caches and reuses Jetty resources for a given protocol/host/port pairing, this configuration option will only be evaluated during the creation of the first endpoint to use a protocol/host/port pairing. For example, given two routes created from the following XML fragments, JMX support would remain enabled for all endpoints listening on "https://0.0.0.0".
<from uri="jetty:https://0.0.0.0/myapp/myservice1/?enableJmx=true"/>
<from uri="jetty:https://0.0.0.0/myapp/myservice2/?enableJmx=false"/>
The camel-jetty component also provides for direct configuration of the Jetty MBeanContainer. Jetty creates MBean names dynamically. If you are running another instance of Jetty outside of the Camel context and sharing the same MBeanServer between the instances, you can provide both instances with a reference to the same MBeanContainer in order to avoid name collisions when registering Jetty MBeans.